- openldap-bugs - openldap.org

Re: (ITS#5024) Disabling pagedResults advertisements
by ando＠sys-net.it 22 Aug '07

22 Aug '07

v_orgos(a)yahoo.com.au wrote: > I am upgrading from 2.0.xx (RHEL3) to 2.2.13 on RHEL4. Outlook 2003 clients have > been using the old ldap server with no issues at all but during testing on the > new RHEL4 test server I've come across the problem discussed at First of all, upgrade to 2.3. > http://www.openldap.org/lists/openldap-software/200408/msg00298.html > > As suggested I've tried to stop it advertising pagedResults but it does not > work. > > I've tried > > access to dn.exact="" filter="(supportedControl=1.2.840.113556.1.4.319)" > by * none This would filter out the whole rootDSE, but supportedControl has no matching rule. > > but this does not work and I've tried > > ccess to dn.exact="" attrs=supportedControl val=1.2.840.113556.1.4.319 > by * none This doesn't work because supportedControl has no matching tule > which seg faults. It's a pity that you discovered this so late; if you found it when 2.2. was the latest, we could have fixed it. > I would appreciate if you would provide me with the correct syntax or some means > to allow Outlook to work correctly. The real fix would be to dismiss Outlook. A workaround for OpenLDAP 2.2 is access to dn.exact="" attrs=supportedControl val.regex="^1\.2\.840\.113556\.1\.4\.319$" by * none The "right" syntax for 2.3 is access to dn.exact="" attrs=supportedControl val/objectIdentifierMatch="1.2.840.113556.1.4.319" by * none > I really do not want to have to maintain a custom RPM or have to patch RedHat's > everytime there is an update/security patch. You won't get too many updates from RedHat anyway... 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#5101) Fatal Error: call to undefined function ldap_connect()
by rharirakdhanu＠gmail.com 22 Aug '07

22 Aug '07

Full_Name: Hariharan R Version: OS: Windows server 2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.164.140.2) Hi, I am using openldap with php. I am getting, fatal error:call to undefined function ldap_connect()...I modified the php.ini file removing the ; in extension ldap.dll.... But still i get the same error...Could anybody help me to resolve this...I also need step by step procedure to configure Openldap once again with php... Thanks Hariharan.

1 0

Re: Calysto v1.5 reports on openldap_v2.4.4alpha
by Pierangelo Masarati 21 Aug '07

21 Aug '07

Domagoj Babic wrote: > Pierangelo, > > I didn't understand the last part on marking submissions private. > Pardon my ignorance. Could you please elaborate? Please keep replies on the list. >> For this purpose, the ITS allows to mark submissions as PRIVATE. You posted to the openldap-bugs mailing list. This list is for discussion about bugs; but to track issues, like a bug report (as yours seems to be) you're supposed to file an ITS using the ITS interface <http://www.openldap.org/its/>. This is necessary to keep track of the status of your submission, otherwise it's just a bunch of emails, eventually destined to the bin. When you submit a bug, you can mark it as PRIVATE. This means that the bug will only be visible to authorized users (essentially, OpenLDAP developers). A PRIVATE ITS means it's only temporarily private, until the issue is solved; after that, all the traffic about that ITS becomes public. This feature is solely intended to deal with issues that may potentially represent a threat to data security, or system vulnerabilities. For example, if your static scan just checks for NULL pointer dereferencing, without considering the context, as Kurt and Howard already pointed out you could find that hundreds of occurrences that a test client does not check malloc(3) results without being harmful, and one occurrence of the server not checking a pointer at the culprit of dealing with requests. In the latter case, until fixed this would expose all deployments of OpenLDAP to denial of service, but it could go unnoticed because clobbered by the rest. 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 ---------------------------------------

3 10

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by donn＠u.washington.edu 21 Aug '07

21 Aug '07

On Aug 20, 2007, at 12:32 PM, Howard Chu wrote: > Donn Cave wrote: >> On Aug 10, 2007, at 2:16 PM, Howard Chu wrote: >>> Now fixed in HEAD, please test. >> Aug 10 15:06:55 rufus03 slapd[31488]: null_callback : error code 0x14 >> Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 >> be_modify (20) >> Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 >> be_modify failed (20) >> I could put some more research into this, but tell me if this >> doesn't make sense. Suppose this mysteriously swapped order: >> a,b,... >> b,a,... >> Your fix increments the first list's index, so next iteration it's >> b,... >> b,a,... >> which is fine, but next iteration is >> ... >> a,... >> "a" looks new at this point, and I try to add it, but it isn't new - >> we just forgot that it was in "old" - and I get error 0x14 >> (LDAP_TYPE_OR_VALUES_EXISTS) > > OK, this should be working now. No joy here. Arguably worse - I think you will find that this one will fail for same-order cases where the original code worked. 1. a,b x,b -> del a, ++i 2. b x,b -> ++i, add x, ++j 3. () b -> add b (oops, b already present.) It looks easy enough to me to code up an order independent version that will actually work. I would initialize adds[] and dels[] with old & new berval pointers, iterate through dels[] and adds[] (nested), and clear both on match. The code is easier to follow and empirically I see one fewer matches in the cases I tested it on. But that's just a test of the algorithm - I haven't sorted out what needs to be done at the end of the function where mcur etc. are modified depending on i == j. Donn Cave, donn(a)u.washington.edu

1 0

(ITS#5100) libldap allows controls to have NULL oid
by ando＠sys-net.it 21 Aug '07

21 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 In fact, ldap_control_dup() is willing to duplicate a control with NULL oid; this is used by ldap_controls_dup(), which is the means used to set/get controls using the ldap_set_option()/ldap_get_option() interface. Since the LDAPOID field in controls is mandatory (RFC 4511), I think those functions should actually error out if they find a missing oid. p.

1 0

Calysto v1.5 reports on openldap_v2.4.4alpha
by Domagoj Babic 21 Aug '07

21 Aug '07

Hi, I ran my static checker Calysto on openldap v2.4.4alpha. Here are the results. Could you please check them out and replace ??? with Yes/No, and if it's a false positive, write a short explanation. calysto v1.5 on openldap_v2.4.4alpha: ??/20 *** Analyzing clients_tools_ldapcompare.bc *** ------------------------------------------ Possible NULL-ptr deref (vc148): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1334 Bug: ??? Explanation: ber_strdup call (common.c:734) can return NULL, which is dereferenced in strlen call (@742) ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc162): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:921 Bug: No Explanation: Pointer arithmetic + lazy summary expansion ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc192): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:846 Bug: ??? Explanation: ber_strdup call (ldapcompare.c:136) can return NULL, which is dereferenced in strchr call on the next line. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc209): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/sasl.c:53 Bug: ??? Explanation: lutil_sasl_defaults call (@common.c:1060) can return NULL, which is passed to lutil_sasl_freedefs (@1071), which dereferences it (@sasl.c:53). ------------------------------------------ *** Analyzing clients_tools_ldapmodify.bc *** ------------------------------------------ Possible NULL-ptr deref (vc1789): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1909 Bug: ??? Explanation: ber_strdup call (@fetch.c:62) can return NULL, which is dereferenced by fopen (@65). ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc1791): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/ldif.c:868 Bug: ??? Explanation: ber_memalloc call (@ldif.c:867) can return NULL, which is dereferenced on the next line. ------------------------------------------ *** Analyzing clients_tools_ldapsearch.bc *** ------------------------------------------ Possible NULL-ptr deref (vc3851): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:157 Bug: ??? Explanation: ldap_parse_reference call (@ldapsearch.c:1394) calls ldap_pvt_get_controls (@references.c:116), which can set ctrls[i]->ldctl_value.bv_val to NULL and return LDAP_SUCCESS. Later, in the call chain: tool_print_ctrls (@ldapsearc.c:1411) -> lutil_b64_ntop (@common.c:1636) ctrls[i]->ldctl_value.bv_val is received as parameter src, which is dereferenced @base64.c:157. If it helps, my trace says that the first test (@129) fails and that the value of ctrls[i]->ldctl_value.bv_len is 1. Don't know if that's relevant or not. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc3852): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:178 Bug: ??? Explanation: ber_memalloc call (@common.c:1634) can return NULL, which is passed to lutil_b64_ntop (@1636), which dereferences it @base64.c:178. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc3853): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/base64.c:130 Bug: ??? Explanation: Seems like a duplicate of vc3851, but according to this trace, it seems that src can be uninitialized. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc3929): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:922 Bug: ??? Explanation: Seems like ctrls[i]->ldctl_oid, dereferenced @common.c:1671) can be uninitialized. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc4342): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/ldif.c:718 Bug: No Explanation: pointer arithmetic + lazy summary expansion ------------------------------------------ *** Analyzing libraries_liblber_etest.bc *** ------------------------------------------ Possible NULL-ptr deref (vc7): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:212 Bug: ??? Explanation: getbuf call (@etest.c:151) can return NULL, which atoi dereferences on the next line. ------------------------------------------ *** Analyzing libraries_libldap_ltest.bc *** ------------------------------------------ Possible NULL-ptr deref (vc44): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/libldap/test.c:778 Bug: ??? Explanation: Seems like vals[i]->bv_val can remain uninitialized. ------------------------------------------ *** Analyzing libraries_librewrite_rewrite.bc *** ------------------------------------------ Possible NULL-ptr deref (vc4622): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/avl.c:289 Bug: ??? Explanation: It seems that rewrite_info_init @rewrite.c:52 call can return a valid info, but leave info->li_params->avl_link[0] uninitialized. info is then passed to rewrite_read @54, which passes it to rewrite_parse @parse.c:112, which passes it to rewrite_param_set @config.c:283, which passes &info->li_params to rewrite_var_insert_f @params.c:51 (received as pointer tree). p is initialized with *tree @190. If nside==0, p->avl_link[0] is dereferenced @289. Note that Calysto finds _a trace_, not _the shortest_ trace. So, perhaps this would fail sooner. Related problem: rewrite_info_init call @rewrite.c:52 can return NULL, which is then passed to rewrite_read @54, which calls rewrite_parse @parse.c:112. rewrite_parse has an assertion that will fail @config.c:59. The pointer returned by rewrite_info_init should be checked right away, and if NULL exit with an appropriate msg. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc4626): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/libraries/liblutil/avl.c:308 Bug: ??? Explanation: Seems like r->avl_link can be NULL. Trace is equally long to vc4622, but the control flow context is somewhat more complicated, so I'm leaving that out. ------------------------------------------ *** Analyzing servers_slurpd_slurpd.bc *** ------------------------------------------ Possible NULL-ptr deref (vc216): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:869 Bug: ??? Explanation: CATLINE(buf) is called @config.c:427, but it can fail to initialize line. The trace shows that lcur+len+1 can result in an integer overflow, in which case the test @403 would fail, and line would not be initialized. Later, line is dereferenced @445. ------------------------------------------ *** Analyzing tests_progs_slapd-bind.bc *** ------------------------------------------ Possible NULL-ptr deref (vc27): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-common.c:176 Bug: ??? Explanation: ldap_str2charray call (@slapd-common.c:174) can return NULL, which is dereferenced two lines lower. ------------------------------------------ *** Analyzing tests_progs_slapd-tester.bc *** ------------------------------------------ Possible NULL-ptr deref (vc59): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:277 Bug: ??? Explanation: ldap_str2charray call (@slapd-tester.c:275) can return NULL, which is dereferenced two lines lower. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc62): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:224 Bug: ??? Explanation: ldap_str2charray call (@slapd-tester.c:218) can return NULL, which is dereferenced @224. ------------------------------------------ ------------------------------------------ Possible NULL-ptr deref (vc64): @/work/benchmarks/SOURCES/openldap-2.4.4alpha/tests/progs/slapd-tester.c:226 Bug: ??? Explanation: calloc call (@slapd-tester.c:225) can return a NULL pointer, which is dereferenced on the next line. ------------------------------------------ Thx, -- Domagoj Babic http://www.domagoj.info/ http://www.calysto.org/

4 10

Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by ando＠sys-net.it 21 Aug '07

21 Aug '07

y.le.ny(a)ifrance.com wrote: >> the file openssl/ssl.h cannot be located on your system. Apparently, >> it's not where you expect it to be, > I verify, the path is OK. > >> or CPPFLAGS are not being read as >> expected by configure. I'm more inclined towards the latter, as no "-I" >> appears in the cc commands in your log. > Any idea to test this case or > force configure to use the variables that are in CPPFLAGS ? depending on the shell you're using, I'd export the variables and then run configure. For bash (which I use): export CPPFLAGS="-I /path ..." export LDFLAGS="-L /path ..." ./configure --enable-... In any case, I don't see this as a bug in any of OpenLDAP's components. 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

Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by y.le.ny＠ifrance.com 20 Aug '07

20 Aug '07

>the file openssl/ssl.h cannot be located on your system. Apparently, >it's not where you expect it to be, I verify, the path is OK. >or CPPFLAGS are not being read as >expected by configure. I'm more inclined towards the latter, as no "-I" >appears in the cc commands in your log. Any idea to test this case or force configure to use the variables that are in CPPFLAGS ?

1 0

Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by ando＠sys-net.it 20 Aug '07

20 Aug '07

Yannick LE NY wrote: > Sorry, but at works, I can use only webmail and > I have no options to send my e-mail in text mode only. Well, I'm sorry but the ITS can't handle MIME messages. > I send you my config.log in an other e-mail for you only. > I found nothing in this file for the openssl headers problem. Well, I've found plenty: <snip> configure:19446: checking openssl/ssl.h usability configure:19458: cc -c -g -O2 conftest.c >&5 conftest.c:124:25: openssl/ssl.h: No such file or directory </snip> <snip> | #include <openssl/ssl.h> configure:19487: result: no configure:19491: checking openssl/ssl.h presence configure:19501: cc -E conftest.c conftest.c:90:25: openssl/ssl.h: No such file or directory </snip> <snip> | #include <openssl/ssl.h> configure:19527: result: no configure:19562: checking for openssl/ssl.h configure:19569: result: no configure:19821: error: Could not locate TLS/SSL package </snip> the file openssl/ssl.h cannot be located on your system. Apparently, it's not where you expect it to be, or CPPFLAGS are not being read as expected by configure. I'm more inclined towards the latter, as no "-I" appears in the cc commands in your log. >> As per the request to add configure switches to locate common packages, it >> should be rejected, as the appropriate way to let compilers detect > packages is >> by CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH. > Ok, that is your choice That's the project's choice, not mine, although I find it reasonable. > but configure switches to locate common packages represent a broken means to > help users to compile openldap. as they do not allow, for example, to sort the order in which paths should be searched and so. > Sometimes users don't know how to > configure CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH for their environnment > because there are administrators but not developpers. That's another business. In this case, administrators could use bundled packages instead of building their own. 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

Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by y.le.ny＠ifrance.com 20 Aug '07

20 Aug '07

Sorry, but at works, I can use only webmail and I have no options to send my e-mail in text mode only. I send you my config.log in an other e-mail for you only. I found nothing in this file for the openssl headers problem. >As per the request to add configure switches to locate common packages, it >should be rejected, as the appropriate way to let compilers detect packages is >by CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH. Ok, that is your choice but configure switches to locate common packages help users to compile openldap. Sometimes users don't know how to configure CPPFLAGS, LDFLAGS, LD_LIBRARY_PATH for their environnment because there are administrators but not developpers. Thanks for your help. ++++++++++++++++++++++++++ Pierangelo Masarati wrote : > y.le.ny(a)ifrance.com wrote: > >> This is a multi-part message in MIME format. >> >> ----------------3f8620ff6596fbde5a10880e48d84784 >> Content-Type: multipart/alternative; >> boundary="--------------a4aca1475551c759da8fba68bbada551" >> >> >> ----------------a4aca1475551c759da8fba68bbada551 >> Content-Type: text/plain; charset="utf-8" >> Content-Transfer-Encoding: base64 >> >> SGVsbG8sCgpJIHNlbmQgeW91IG15IGNvbmZpZy5sb2cuCkkgZm91bmQgbm90aGluZyBpbiB0aGlz >> > <snip> > > Please do not send html messages to the ITS. > > 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

Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values
by hyc＠symas.com 20 Aug '07

20 Aug '07

Donn Cave wrote: > On Aug 10, 2007, at 2:16 PM, Howard Chu wrote: >> Now fixed in HEAD, please test. > > Aug 10 15:06:55 rufus03 slapd[31488]: null_callback : error code 0x14 > Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 > be_modify (20) > Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 > be_modify failed (20) > > I could put some more research into this, but tell me if this > doesn't make sense. Suppose this mysteriously swapped order: > a,b,... > b,a,... > > Your fix increments the first list's index, so next iteration it's > b,... > b,a,... > > which is fine, but next iteration is > ... > a,... > > "a" looks new at this point, and I try to add it, but it isn't new - > we just forgot that it was in "old" - and I get error 0x14 > (LDAP_TYPE_OR_VALUES_EXISTS) OK, this should be working now. -- -- 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

Re: (ITS#5097) slapo-refint apply to subtree renaming
by ando＠sys-net.it 20 Aug '07

20 Aug '07

zhangweiwu(a)realss.com wrote: > It would be nice if referential integrity is maintained during subtree > renaming. This is now fixed in HEAD. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by ando＠sys-net.it 20 Aug '07

20 Aug '07

y.le.ny(a)ifrance.com wrote: > This is a multi-part message in MIME format. > > ----------------3f8620ff6596fbde5a10880e48d84784 > Content-Type: multipart/alternative; > boundary="--------------a4aca1475551c759da8fba68bbada551" > > > ----------------a4aca1475551c759da8fba68bbada551 > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: base64 > > SGVsbG8sCgpJIHNlbmQgeW91IG15IGNvbmZpZy5sb2cuCkkgZm91bmQgbm90aGluZyBpbiB0aGlz <snip> Please do not send html messages to the ITS. 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

RE:Re: openldap-2.3.37 configure can not find openssl/ssl.h (ITS#5099)
by y.le.ny＠ifrance.com 20 Aug '07

20 Aug '07

This is a multi-part message in MIME format. ----------------3f8620ff6596fbde5a10880e48d84784 Content-Type: multipart/alternative; boundary="--------------a4aca1475551c759da8fba68bbada551" ----------------a4aca1475551c759da8fba68bbada551 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sCgpJIHNlbmQgeW91IG15IGNvbmZpZy5sb2cuCkkgZm91bmQgbm90aGluZyBpbiB0aGlz IGZpbGUgZm9yIHRoZSBvcGVuc3NsIGhlYWRlcnMgcHJvYmxlbS4KCj5BcyBwZXIgdGhlIHJlcXVl c3QgdG8gYWRkIGNvbmZpZ3VyZSBzd2l0Y2hlcyB0byBsb2NhdGUgY29tbW9uIHBhY2thZ2VzLCBp dAogPnNob3VsZCBiZSByZWplY3RlZCwgYXMgdGhlIGFwcHJvcHJpYXRlIHdheSB0byBsZXQgY29t cGlsZXJzIGRldGVjdCBwYWNrYWdlcyBpcwogPmJ5IENQUEZMQUdTLCBMREZMQUdTLCBMRF9MSUJS QVJZX1BBVEguCk9rLCB0aGF0IGlzIHlvdXIgY2hvaWNlIGJ1dCBjb25maWd1cmUgc3dpdGNoZXMg dG8gbG9jYXRlIGNvbW1vbiBwYWNrYWdlcyBoZWxwIHVzZXJzIHRvIGNvbXBpbGUgb3BlbmxkYXAu IFNvbWV0aW1lcyB1c2VycyBkb24ndCBrbm93IGhvdyB0byBjb25maWd1cmUgQ1BQRkxBR1MsIExE RkxBR1MsIExEX0xJQlJBUllfUEFUSCBmb3IgdGhlaXIgZW52aXJvbm5tZW50IGJlY2F1c2UgdGhl cmUgYXJlIGFkbWluaXN0cmF0b3JzIGJ1dCBub3QgZGV2ZWxvcHBlcnMuIAoKVGhhbmtzIGZvciB5 b3VyIGhlbHAuCgorKysrKysrKysrKysrCgpEZSA6IG9wZW5sZGFwLWl0c0BPcGVuTERBUC5vcmcK RGF0ZSA6IDIwLzA4LzA3IDE1OjEyOjMxCkEgOiB5LmxlLm55QGlmcmFuY2UuY29tCkNjIDogb3Bl bmxkYXAtaXRzQE9wZW5MREFQLm9yZwoKU3VqZXQgOiBSZTogb3BlbmxkYXAtMi4zLjM3IGNvbmZp Z3VyZSBjYW4gbm90IGZpbmQgb3BlbnNzbC9zc2wuaCAoSVRTIzUwOTkpClRoZSBmYWN0IHRoYXQg T3BlbkxEQVAncyBjb25maWd1cmUgc2F5cyBpdCBjYW5ub3QgZmluZCBhIGhlYWRlciB3aGlsZSB5 b3UKIHNwZWNpZmllZCBob3cgdG8gZmluZCBpdCBieSBhcHByb3ByaWF0ZSBDUFBGTEFHUyBzaG91 bGQgaGluZGVyIGEgcHJvYmxlbS4gCiBQbGVhc2UgaW5zcGVjdCBjb25maWcubG9nIHRvIGRldGVy bWluZSB0aGUgcmVhbCBjYXVzZSBvZiB0aGUgcHJvYmxlbS4KIAogQXMgcGVyIHRoZSByZXF1ZXN0 IHRvIGFkZCBjb25maWd1cmUgc3dpdGNoZXMgdG8gbG9jYXRlIGNvbW1vbiBwYWNrYWdlcywgaXQK IHNob3VsZCBiZSByZWplY3RlZCwgYXMgdGhlIGFwcHJvcHJpYXRlIHdheSB0byBsZXQgY29tcGls ZXJzIGRldGVjdCBwYWNrYWdlcyBpcwogYnkgQ1BQRkxBR1MsIExERkxBR1MsIExEX0xJQlJBUllf UEFUSC4KIAogcC4KIA== ----------------a4aca1475551c759da8fba68bbada551 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sPGJyIC8+PGJyIC8+SSBzZW5kIHlvdSBteSBjb25maWcubG9nLjxiciAvPkkgZm91bmQg bm90aGluZyBpbiB0aGlzIGZpbGUgZm9yIHRoZSBvcGVuc3NsIGhlYWRlcnMgcHJvYmxlbS48YnIg Lz48YnIgLz4mZ3Q7QXMgcGVyIHRoZSByZXF1ZXN0IHRvIGFkZCBjb25maWd1cmUgc3dpdGNoZXMg dG8gbG9jYXRlIGNvbW1vbiBwYWNrYWdlcywgaXQ8YnIgLz4gJmd0O3Nob3VsZCBiZSByZWplY3Rl ZCwgYXMgdGhlIGFwcHJvcHJpYXRlIHdheSB0byBsZXQgY29tcGlsZXJzIGRldGVjdCBwYWNrYWdl cyBpczxiciAvPiAmZ3Q7YnkgQ1BQRkxBR1MsIExERkxBR1MsIExEX0xJQlJBUllfUEFUSC48YnIg Lz5PaywgdGhhdCBpcyB5b3VyIGNob2ljZSBidXQgY29uZmlndXJlIHN3aXRjaGVzIHRvIGxvY2F0 ZSBjb21tb24gcGFja2FnZXMgaGVscCB1c2VycyB0byBjb21waWxlIG9wZW5sZGFwLiBTb21ldGlt ZXMgdXNlcnMgZG9uJiMzOTt0IGtub3cgaG93IHRvIGNvbmZpZ3VyZSBDUFBGTEFHUywgTERGTEFH UywgTERfTElCUkFSWV9QQVRIIGZvciB0aGVpciBlbnZpcm9ubm1lbnQgYmVjYXVzZSB0aGVyZSBh cmUgYWRtaW5pc3RyYXRvcnMgYnV0IG5vdCBkZXZlbG9wcGVycy4gPGJyIC8+PGJyIC8+VGhhbmtz IGZvciB5b3VyIGhlbHAuPGJyIC8+PGJyIC8+KysrKysrKysrKysrKzxiciAvPjxiciAvPkRlIDog b3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZzxiciAvPkRhdGUgOiAyMC8wOC8wNyAxNToxMjozMTxi ciAvPkEgOiA8YSBocmVmPSJtYWlsdG86eS5sZS5ueUBpZnJhbmNlLmNvbSI+eS5sZS5ueUBpZnJh bmNlLmNvbTwvYT48YnIgLz5DYyA6IDxhIGhyZWY9Im1haWx0bzpvcGVubGRhcC1pdHNAT3BlbkxE QVAub3JnIj5vcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnPC9hPjxiciAvPjxiciAvPlN1amV0IDog UmU6IG9wZW5sZGFwLTIuMy4zNyBjb25maWd1cmUgY2FuIG5vdCBmaW5kIG9wZW5zc2wvc3NsLmgg KElUUyM1MDk5KTxiciAvPjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlk IGJsdWU7IGJvcmRlci1yaWdodDogMXB4IHNvbGlkIGJsdWU7IG1hcmdpbjogMTBweCI+VGhlIGZh Y3QgdGhhdCBPcGVuTERBUCYjMzk7cyBjb25maWd1cmUgc2F5cyBpdCBjYW5ub3QgZmluZCBhIGhl YWRlciB3aGlsZSB5b3U8YnIgLz4gc3BlY2lmaWVkIGhvdyB0byBmaW5kIGl0IGJ5IGFwcHJvcHJp YXRlIENQUEZMQUdTIHNob3VsZCBoaW5kZXIgYSBwcm9ibGVtLiA8YnIgLz4gUGxlYXNlIGluc3Bl Y3QgY29uZmlnLmxvZyB0byBkZXRlcm1pbmUgdGhlIHJlYWwgY2F1c2Ugb2YgdGhlIHByb2JsZW0u PGJyIC8+IDxiciAvPiBBcyBwZXIgdGhlIHJlcXVlc3QgdG8gYWRkIGNvbmZpZ3VyZSBzd2l0Y2hl cyB0byBsb2NhdGUgY29tbW9uIHBhY2thZ2VzLCBpdDxiciAvPiBzaG91bGQgYmUgcmVqZWN0ZWQs IGFzIHRoZSBhcHByb3ByaWF0ZSB3YXkgdG8gbGV0IGNvbXBpbGVycyBkZXRlY3QgcGFja2FnZXMg aXM8YnIgLz4gYnkgQ1BQRkxBR1MsIExERkxBR1MsIExEX0xJQlJBUllfUEFUSC48YnIgLz4gPGJy IC8+IHAuPGJyIC8+IDwvYmxvY2txdW90ZT4= ----------------a4aca1475551c759da8fba68bbada551-- ----------------3f8620ff6596fbde5a10880e48d84784 Content-Type: application/zip name="config.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="config.zip" UEsDBBQAAAAIAMiMFDen4FoKJzMAAHMdAgAKAAAAY29uZmlnLmxvZ+w9a3fbNrKfq1+BJj3No5HE 98Ntc49jO4m28ePYTprupldLkZDEDR+6BGlbu73//Q4IUeRQoOV4+7ob+dSOhHlgMBjMDAYgezkP GZmGESV+muRemDDiJUsSU8a8GWVkkaVB4dOATJaAES8AM2Pkeg7/9rIiScJkximn4azI6DOSp8QL AxLQSTGbcVg4rcEk9j5S4E/ikOXwcdDrjXJy7THiZ9TLRSc1M96LP+fw3owmNKswXp28JftFnnJM og1Md0DIKLlKfS8P04RLGXtJQKIwoSVxj5CvyGBYi9HvLzI6DW++H6aLHH5pEgXeoq8N9IFuAzQI mTeJaJ9F3iJA34usbLgO83k/j1j10V9mBeszj0Vr4BxGFHAEmgjauZdRxCwHcf0KfxH6vd7Dh6Rf /ZCHD/n3s8jLp2kWD8R3DO/NU5YnXkzJ98SPbmLFu+4V5fd+DE2sSIyiasigwRw41VcGXy+K5PSi ariChldcy6E/VlVbN5W+qvV6w4Jlw0mYDFdoC8534WV+r9n6nsAP57hkOY3XrE/SoCnaOY2ox+hK kB9oltBodCjt99jz5zB960G8KNjlcsG/f1ckH5P0OnneuwAaL0JNbxkYJ2o5PTp+CA1K7zQLwR75 Z7V3UsQHZ2/Lj2IYMJ45QT+i43L4NUb/I4IWAgx2dUVvhjOasyULk2kK4FX/5QTxJsy8RhDdx2K0 MoRagpRF9IpGcg5FEl7B0KmMQ+9s//L1HikZRbBIIk7RaGx/Za3vvs8aKINebafIUg/SjJKcspzV toqtdb0A91RLtfaIP6f+R+4jJkUYBYQJ48lhnhGqbuyRjLIiyveE6fVB+X2WRl4WMm3gIGRDa/Dl 2u9ka1qfwNYyGmxzL5vRbsa2c3fGtmI3GMNCJx55cXHY554W3AP4CRIm4CmiCFFZWt0FntfhCp30 fURh641+ruc0n9NspXeaXIVZmsQ0yUnICPMSNB5HbShqSRmCOWpL/Jl3/bGJ4apKTZ2ktxPH/w5x 0iJ2XHsPAAVEgvUaauO4it3oYKN3W6IzHsIIozkjXz0+3v/h6Aki0e0uXWmq0TT5OhiBMRVc901k 3bLcPfLj/vnJ6OTVHhFxaBU4gmcknCVpBlzq6DIJJmtG/w6f+a/EJ06TME+zX4VXRiNvKeVkq84n cWLLxId85krKzLEacxekaBEYiq63zM33Edxwa2ND67GFZ7p1Jy2Q0+7CyxDcrbpAbnmIsVSl0UEL ZDmtDli+jChJp+Bj/KgIKCmYyLC4kSNSt/YBPP1qwky97cIO1oki4UEJcjKEbyiAzxOfFZB8Nwzo 1TApwGs9/9rsAezxq4ODJ0QfGAOrd5AulhC75zl5DG2aoljkZUYpuUin+bWXUfKS66RM/Z5BGugP emVKy7NajsZWaN8SBt/yOW8pMp+KSQTeq9UYhJwDxC5yCcuccvqT0x5QZl6SL78F95MTiL9JSXd8 dH7wev/kcv/F6M3o8icCTS9HlydHFxfk5ek52Sdn++eXo4O3b/bPydnb87PTi6NBDysBJvur/+KZ CW42hW6u2ko5p17AJWUL6vORpXHT0KJwMpz5/lAWboalGoclYe+g6isgPO2EcI7yYpGLeux7bGGs gkQBhkRBO8Gtv0deMiv4FuJ7/5n/zTfPprbduyyzYhKnAY32yCJl4U0P5K7MRMw4Vogj1ZO5sqF3 m8azR/7ef/eIQGbPOcYFy8ncu6r9LOZTTYOKmm2r26QDOvVgHZC0yBdFLrZOPAvGDNxSPvjhrTwr GviEC4iwHE02OEtzGkt4AP0gqC6L5PCnKeN1mn1kmAoEGgw3uRlyEUwXxTEEsyyJANdcwZT4WcrY Sg4AYzpHHswBZLeDOSumsD/jroneUL/IuUUxTKILC0jXGpZoG1NYsqHailqLhQF2p1Dp5B/UF3PP EI3mCKl8JEtbFFtXpaKYei1KiiF2t84LxhuhhXvmhhUgBo56J8EcWyqYC9Slivv/JL0vvviC/PKL +P4l6bOaH80yTGbIudmCG6JF43UURUbpqDoySwxzJSqCIXu+Txc5uLAZQq+ikA+AtkowoiUVxVTu oRIg0+XcrK0qMV0ppa10q8SxN5KWyi/m6UoxZP/kYkQOmnSuaQvvJZTTP9VuU5Br1UNCzfZ9FOTa ipSbrcsUhFEsKaVrNN1OQklCaUCDBo6pqBof8Jbxiq97gAoyp9kegXQy927ENzKhoGBKHsT0AWbt SCIMmXqwQgNeXJtlXsyrVHu9X8jDcJpAeCHjsb+ICsZ/oZXAHKaw6YgpR6GQqUybPahmMyAEdAEY NPGXdXaH8kxTM3SsEAS0lI39KM8J87mXkyClrMyD8qxIfC+nqxjYZKCrRufWFBhh1LZ50llGFwhF q3NyCdRoZ8xRsE5h8aCN5k6ylcIgPORFwmnpViGSfaQZedyie0JCVrrcFgsdGRwGuVjgtiiN1ZnR KPUCFGkQK6ORkfczBLIM3Eu7opDETXRTsTpUk8RQ70OoqiLxsVECi1KkHBjZQJ4JwTQVlWmuxYj9 dJaEjK6NOAfVTzLIYzG15TYseOExNsb1EUs1XAn7IlmlSYuMwsLzKWNphsgcQ7iBo+b6RxiuzDtZ mqZJCWunATUUnhp4/pivuJuQ5TC6AeTfJylhhT8XaSRMVRCCGvI0W2L+n+BEhk9LGcCPsMF8QMjT ITRyzwEtYUJha3Lww/6ro/HJ/vERefBAArncP+8Gvjs6vxidnsiBF5fnsBWXw168fXV+dHZ6fonB p2dHJ28O98/GAg96PYXJ5y0yrLp7Uaxv4qzgJ4en52s0TdF1+3ac8fH+X2DPpm3DGp0Alr4FC2qk B68J6vL1/ruj8fEPlUSqmCKwb8k0Paw24t+1LeU5sodGqULYHYK6qsQaMYYtM2Ndc39TM9Z1c2fG OzOu7cFuh0ORi5I59QKabQQ9y1CM2/M0hKzWvho1G/fIS4HMlnLTFFleilF0GaWpuBsbWDGozW0s olM1KTs+rMGwIsQgW0qhayg+I5jZLoCwJRvykw6YZYRob8mcMbIjFcTR7jEjQGbKuTnbZsR0VRml pXyqQvgR7k4fVS05gGRtp41KGxl83GlDaCOmMaQCO200bWPnSFfqCJN8F1iwIw2T+4SVKkmHQiFk JYLP3ZNz097tMf+TkvMKdHF5eDB+fbR/CDAOwDQXP12ML386O7oYv5YCQdv7lzIYsH0zeiGDiPmR QY6Pjk/Pf+qmkQoxOrmsBLzjnoMbfgpbDVFQ3RgnbyY1cp3XPq/LqxUlUgImrPO/Nh1SOSaqkqTn G80wmIpTxKgAT7Gqy8YuXqJ/LAiej4rnl8givv4azU27ExG5USdYdBHMJErA8yojkqocTzkmqyNF p6KAVKYooNyuqLcnI+DQ7rRIQmDQEpV/lvDv8vlJervLF318ngHQ0pzm8UU09ZPBnBTMm4RRmC8R qqFsUQlCtqSi3OvcDsh0OTdrm0pAJ1JKy+1Wia1LVLIAbJr4FGE6uqRihzGk3dtKd/e20To/qERA SKbazQBdNOI199i7CeMiJhFNZvmcpFN0SVt6Bc5yLKXuQbM01TAQGN0ZqNjlKVl4GaOSg4z1hY0s jbnOxMlKk6Vr2Xe3L/lBJTQbslOUhnGQD7+UR2r9hPQpecSG/z14+jfyxc8fHv/txeH55c/i79MP T3gj/30KkPF+/69e/58/Vx+UvstRvhp+UMkHDf4bLh6RD8/rbpIYSyUrAdmKdqcalPjI8niQYi0A B12TMm6eSqcfMahtXTARkJEiHKdhnQOIcqwJ1cx22TDzEkBCOLYpvSwnwXSsuq9NsK67ku3bAqGY 8r42Ea1GVxtQcDH46BEmZvWMwDTyZkScsCEKB61BDHPdTW7FYpFm/CrENEn7WZ6H4hO98Wl57og4 2Frb23bTbawTHyS79rIEOt9Da7064Xyw5vWAH6NeeVEYiJtW33wzPJ38A/4hkyLnx82iGYtmyKzO xievCGS4t1yFqB5yIWcj1I/bvJDTn7ahlrqhYkApZ0tgb06Z62xEdYHZP+R/sRoxoSUbsut2Xs52 FE25xQT4qi93hIMUERnGhoApd53r0rI2SFtyYnqciVTNlt0tp9t1o833O8/e65GIe4fSk2LHdTrD nKuopqTbfuQDx7SIAjKhhN4sotAP82gpBAlImCAe2paMBCPjHKJq1kXUWV+g/DF61p+X/1S8kINu RBJ+T1T78PzD1yoPKvx6BCkHAJGgvhUpEFCPRhW6cLOpdSsL3QsJlokXh+vJ8UFwz89pFjLwVojO al4CqO+kkigYsBQjOptH9sA38NOAriZ3CbE9nzNeMUqrigTurXm1JYxjGoReThGG7CKd8MULaKmt iDulRcpYOIkwA7vrFqNrOxv3q+fRmN/iaGI5hnn3c5+3idgKB5CoTsMMUDM6pRlPA4MeYct4kkaE ABBoQS3leu5VvZJbfoZXXjbM48UQ1lQxZR+zG3ADUcDrPbkX7ZELwbrqDQYkrjmxAVSTqkzqOgvz nJYOtHHuFEXUz8GSogDI8yID6YkKKynMy3BWMKQNU91VnXZVpz971QnBRJ1ABjl88/LgZFuhCgCH gqZaqOVlzATWb5L6RVrwbCgLvSR/Bk3E9xjUGKIwDnNe+CAB9cGLUramHgBP+HmZZrDIvHgR0Wfk 9Vn/7XuiqqGUckYh7YppOg285bp8FmCZamnGVRNgCfHFU57VKT0Iv6Idj1leTEjs8VvghGd883RB p0UE4XNKr/lyztOygvNMyLx6wNf3klJPEGrz8rGEMqLUojx+8i0E4yi9HqzIzkq/1BwbCPGdxxjN cv4tnIIspQmOuR9f+dBnhIXgOAWPJnF5PYGJpzvSpHxshOUgPni9+pHnpr8JYUrrLlC9SLBFJSoE FkJKyklFwnlu6Pr0CvxuGNDyoeyZ72s8+tEs8aJanaX9XKVhAEjCTddF0enmfVJ6wxmQBwfcxfyr KQf092P5EJCYgAn1PfjCeyRx+QRO7OX+vEzNhGsnZffplHilbEK1/KnCPEy4AXDUhIA+1lv8htTX ZZbF8jCKiLdYRJUtbs6+EO2yuuG+TgfExDLoJWRlwJ0WiS82JMKyIOaEfEXwnpmQrlRWdO0tWRll hL0dnZyC24H+L9KYNrh4GSjezwsPTLh8yCNYMWGAB70mMx7Tshw+CEbjcTVskqRZ7EUlFRghNEO3 occaU7OSH4YoVs56pT2BotQGcFyDgRxdCQYrq9T2+On0CagMAmqF/W09wx0G8b/YFvl8w9/YCxPg JGykmm8oH2POhJR/K7jyLeeHIrxtdSVMG89wNr0PJLJBhDInV1XvkjkJQiISqDqlqYxGgLkoudi0 N3Fe8hOy1d3Q3yzncVV7l/Pscp7PKef5fWLZ/4c4JvOtGGW7S3XxExwY5GzU7lNYgQ0cVVGU33oL Kjol5K5bUHb45t0PPq9oPBYcy3wvmTFuDmEsijDNZ1vEkyXhhP8G0YClA/XJH7B/BV2quw3szpl/ Vs683sCKZX6/7aug/XU3r4JnY+sqGn7vjavo9XPatooR/26B/k+7aRV6+Jy2rGLEHRtWAbzbdlXg /vqbVcG3M6/CwVxHe1UMM1RpZlVtVTGyffetqtipYvL6uB63O3d/Dh/TGR38JE/iYwxXkVKqCn4S HwE125EcsnhVNsTd5lp5OaPRFFHrptKpu/4hClMSXbZVqdcXd3C7reIBYKAlHYA4jvei+jjwbkMy DOfuQ9o+JsNUpWMyWneKMNDV8GkweKQ8TaPOg9Q2uXEbb1t2gpuKF4zdzthUnW7GpqbexljMRxdj zexczJbKBc6ox91gpYkmBn+L2z0eIVZV27Vaj2YisKMpsgtbGKU+6UftprPl6Uzt3k9nig4sY7eV 2W1lPqetzN0eVFVVV2sH/wkdQ/ongv+EYmTzjsEfCOFPlqYAjxKad5esARNVrGUonM9WJOjlDyx9 c93sat87H/Of6GMqwNH7o6P33DJ29XDpFlk4zu5qOELYvmdTXUfvSvM0XXG2vpoSE6jqZ/9uSq6F eruI263d2ylbGnHlmtLUX+P9lJxRnZPj9nu8EBBzcPAOvgXc+jI9hG8YSjczw7zPa+iA0LTkr27D SM5v9e42zvs3fnmbqtna9re3IQJH1bFSMNTQNnUtuJb30jGyaQjVHTdU1sKwpfbtNKonQI5hbjtX 9qZ1oQybhqvdNVVmt13oYH9kTguD2OW0u5x2l9N+vjmtcHDdOS1C2J7Taq7ZmdPq2oaHP3pxcDg6 wEiWsq1W6O7pzh5oev/iYDQaj4fV/2FnLCbk1qoh7sraeb+d99t5v/J49MvHj44fke8hX7oJjCeo wti51PChOl5cjt3tCFx7+9vzEIWu6lsOH/SODY1uKM6dr4xhQlWVM1R19L46DLPkNDo+s8NA00Tq EP6Kl3LFy4urg/fD0Tmms90t+weE7Zhy0Rz3HiezQOdqcn6uKX2xAMZxpLRm69l+DNRa4aNKo6v/ /Rtv5sEKtIcJTe1eFgCEHWJa2n1UBnRmBz9nU2UYw5bbomWoeEsFX/6nAOsJEJpt25J3AF574drG QkagnDJ6P1BJ/bplxMNRnE+wNkdeiIF2516qczRVzk8zpNaGcWw5re50W5tjOLLzW5rFYQrOc70o L0enB69+HJ1c/BWT22Ynb0NBZzJetvCGwCtHLw9B+Lq+RfUYu3aEqN3Q76N6oLM6+Lky1WMcU5PT Wtot6rEsqXrqF4lgdNvaEhsgBMjFUJVbxFD11qJpioIxDeOTJpvfUmI02803mm+Jhv4kU15Jc/9Z Z0C+W99ovpFu/gyLW8hx7zmehHn1PrZ7zjMu+Fr2HsQ2xPbWjS22kN3G9v/YO6OWNoIgAP+lXrVG 8iAc9iiBVMMlIH0UGyUQkyNJKf33XW44J1luUWcPbxO/V9cb1t0433wzcEFsP4nYvu10nDwVN7PQ 0dzlo9a1vJzkbttFcLH+t5gWZev61C3MePsjb39M5u2P+mHb58pVmN2rdQDdHvLeiW/F3NmZDXMC fjAH5sDccWEunHmyljfPhgt2jRMs2iVMuGZ3K4t1Z+W6a0BLRCp1Uhgp7IRTGJU6lfqHVeqCFHOR Lo9H1OfKNUpzuAbXTphrmmrMVbmEMBfkm38VcxLN497RJDAmkW2YpySCi46U67L+tigJiXPBJth0 rGw6WLkuf02QMWQsRRkTpNhtTJ6P0LHzPebhYzAP5n1G5mkaspuaxDCrmtOj1RpV0yTvHU3/qibb MKva48Nqt+SC9YK9o+n/gmUb9gteLLuafg6+1F1iF5HpJ1UJVckJViUHC0VZ3ty2LbgjmI1xd9w9 QXcXOpnVXR63m/tFg0gGqSASRILIVxGpWSvO9CWEVfSf5rt19FBWPcG1LyUkIzuyIFmQLIgoIApp iYLgyW4K8nyMKiglGfJBSSgJJV+lpCauOFmQGHZb2FTMjFqhsKn6nxi5TdjnRZ0Ni7Jh5v5gJkWg DbSBNn/hRznBC/HCBL0wZnoUNToa1MBkbgQwASbAjAJm7CwpYpDkCPZnt1h2JhEueBMTkyAxkhhJ jJgEJnEMJtFgy6oTyj27U+zzE7GAn/ATflr5qSktzi6aIHbFeF7stgygFBn+2fQ/g5J92MdQ9Tez zrljvWP/bBK4Y9mH+Y6f75cuBHesd+yfTf93LPt41x1nX70YjSh4vzZ46+ek2t5XHfWTvg2zy2Ed kGYSxTDFMMVwazHs/3g8+jmaTVtXbq/zcdF6p/nYLYZvm6YVTasEm1bCRmvHSp62tqvOsxc806sC z+AZPB8BnjVjWhtiEsHYDav+/kahlUUHB9O/P7tN2BskDl4P8+22I/e9qGdBEpPvGYSv8BW+9s7X g5XJ3XesGCtO0Yr/s3e1zW3bSPhz+yswvQ+1U7fm+0ty7UzqOImnrp2J7TZzNzcqI0E2rxSpklQc 96b//RaEJGgZQKYpJ1bb9USORewul8+C4LMgXuRTc4PEWBrYIDd2Vh7ftH8iPb7p8U2P7z/x4xu1 qL0TZ2mkd+5cXcKjhrJn9cBqQfPw+bN0o3cGXV0lo+KaIowijLDZghBLP3rHWNJqijGKMcJmC2Is /dhoGMkiB2mJhXe3UfUfiwL5IH9Pow9xdcPobMX4Q+VJ72YFMv9xSmMQcaQxOtswCnHhycaR3njl k792qNMt2OxCubJRsGlXk7XB3pKdTZQrGwU7LYa0w4k52ADPNuxyolzZKNjTpEwmFGwVbA082xFs 6cpGwQbJYlYOiaGpeOsR2hKWprzZJOoVzzbfXPgvHPMGny3YQ1r5smG8i+GvnOKt4q3DZ1viLX3Z qJtHvXHfoI9mHz5ZcUm1RtUaHT5bUmukLxu1EnU6IR6Ao43R2RIOIDzZvH2Q40M2aiBm1N1jri+z bensmW3S1UPPAHOUt6j936jtr3k5SQt6HYOCjMHZgrcxc0c2a/jlEL3+rf6MOIKposy2gyDM7soO XDvAJoRkkb1r2XBd7w6xdT1LXQw67vWJLeiFenu+pY0tlnH1usE6VCKrhUrO6xQ++/Vw2oYmju4A DdRHrTtQAXpB49m23p7taaHBMqFe14nM0MCPjmUMS95uWLzA6z63xrZgco37WBnrPj7XCy0an0vj c2l8Lo3P/XTjczGmLyDS2oKXT5+d/myohc8On5trlLnEVOEP3yAIcMSfHwEI5rKjU1OhCJGx8Oj0 AIUJFb56+vrpj6bC14dnpxevD4w+nR0eHx6cG0tPD37AldR84+My+ByfvjCVnh/9CB71aGsu9ACa z3Z++PrHo9M7Ng0XJv8Emsc/6UrgXm7u5/MDWuKX5oVt07wwUfs+aCxQNVTvuLEu/MNyijJ+h4lh bJ7F4H/YK5peJsM6LXIsF8SSxBZL8rpgs4jOfkD0/dBX5Bodj3sRfd+QIPqR/yHRb0lEWs3AsrQ0 34xPxWsCBwrDMGqBI1/bIaHI9buDc5HLVnsE1zxOSxAt+ZiXoidh9DkkRZO3RcaYAISJG7PJiD6X J2Vrf/bfJeV+PZnu7w+H0+ff/1CKJDAbifSoTrLH7EyaXpxNXA+AW5TVNyL7Kmb1dFaz6zKta56z ulgFMRNvpgH3bATq9awE75nNxJhhJtr1WYXh8GzK0ihLoyyNsjTK0ihLoyxNn6VpHTx68fTgXDW8 uOjs8Hx9YgcFz6TKnDDUBUtyYBF5MZwVs4oBRUiTvN4TxGKYVECpF2uPf8dGfJglwIPmut+APfh5 XpTwoE8m04zvsZevvr54w2w71epd8lq8kyjGo+RmmWqOkD9LTwbyAEhIt89uqppP2BVPRrwUbs/1 BoOqnr1lk2RYFhVL4Kqviikfz7Lsho35tWATddFkOnvSX3Z9lQ6v4OLyBp8sHQKpSWs4cpWUCzd2 dp+wtzyDiZRzpVcNK1q9KnDhn0lV8bIW39IxeNK08AOWVnPnRnvAlIG2zW0oZcGMqrpi/B3PWQEU ruTAo8B54Fzg1WQKRKisFNmROZI6BcqqpFmcyKli5WQ7cfrHLBc2WzifvgPOl4Jekt+wy+HQAUM1 L/MkU1A2teZdkY5ASFLEuavKz+E0m1XiAwf5e2GAfXEgnob/U1405/uZs1nFJfhv+TCBL+KMbJJe XsHvpIZY1Vd8TitZc/pizJLGNwns21ma1Wkugi9EcwZosKS8nE04GFJeXxcz4KdVnWYZS6bTbFEH 25GXjp3DSV+cXLADscNCmZQ386BWcI60apj+eJY3WWI1r1Mp1F9xH4jzVtK3BqrsOrmpGnora9rh ySk0NHD2s2LClRXwGWAf1rNEVN48mfDR3EgFcvWVnIKalDX8IQ0NBouLZnlRTpKs0WIpmAI4sjSp VgKzqJRsR94z8ztsV+RV7aLBorBBp/iVswlXtUsCtvNovAtwAYuXsk9UZA0V4Q9cA0Wc4fckSXOw I+vGIs7QtbJqlzH5e15qPRHWcE4RBMYEPwpdnKPJc8K/rzNdthaHXbK1pTL7MKmNLfWmER8PeyW1 sW3p7dmuJqnFEoFe04nNSW3s2UbAct46QdApt5WaTIHWYKayz8VdJuVECGs4MTRRqzLP04wvlqn4 eOlpHFJ6SukppaeUnlJ6Sukppaf3np62brXvJfzrM1cDY1TfutHEOA5NNNG3rNjMeqpsUGFp1+3G e6RuF+YjJR+S+/i0PjFxH+I+xH2I+xD3Ie7zl+I+vhX4Zu4Thuu4D5K1Lbs782nzHmxIDTpHx227 Ty8Z6HkGe6GmlwxJOJZe03VRLxku9Hzt0A+JGgS5dY6wW0eZVGUSvi6sMX3gDjPfjqjDjEgjkUYi jUQaiTQSafyUpLFddHJ2vIZMfrLX/Nv/il9Hp6VAZ0LtWObORMc2dyZe8hzLel27EkFTTwyxuVhL Zh2/13Rq0AsM9uJbaLUTOHrN0DfTaie2WsjJha+QkOuF3SG7FTE0MRgdD3sh5gaW3l7gahDDEoFe M4zMiLlx0HG5MN+z7DvbEaDdyY6Phg80g6/ghl7er5UpqH7YfWY5SEcKZHy818xy0Av19mL9zHIs o69AgRUrmKDF2RuPBhWv2aO9qi5nw5qJ8XDvkow9wmpuu/GYQkqGReLgHm+A0FI3Kj4e9MES9GK9 PdvR3ABYwtdrOqG5woX+aoUDrNAStVg0uG1lCixtuI7Q7YdLGBjsxbfWsTAyxCh21iATBxgZ0+q0 cDfpFqbAIrbeg8hd40EUtHuWpBdYKPTMFmLLaa+pvDbEsX2XxQZsVyw2oMx2XmzAjx1abIC6Pajb g7o9qNuDuj2o22Mbuj3ax18cntxboKWKCIholF7YgtCbix3XYzsLur9rlvPZDs4FpDS+/U+P1eWh o7SSA63ksEUrOSyNKzb9HebMnou6zHBZqOH5xoQl9sNbdvkN497UPnCJ2hO1J2pP1J6oPVF7ovZE 7beZ2hvZVmRkW4FltxcuWjGDJR3fbCWKlZX5TP9EzGZmxVgYHPCyzIAqIiXbDrt30LKjfDlFmv0i XqJ++Xi1HN7OyJfTj9kvKyf8ks1y6Y6Y1izXUZIvnuX87YXJXYOtncNkeLVqIx3xvE7HKS8ZqJcA VFnD4SLPbuDXkBvsCGA5mFLXkNbi1TRPygqc+WYXI+MQ7yTeSbyTeCfxTuKdxDuJd24f7zT2Kut6 j3HBfAPi79QQwp+PTk7OpQzqwEU9i9rBenJI36MhcKUd+ecue7RCALuM4AtsLzJSW9tfobZyxSbR B7mW2Eb2PQzK6Uh8I//+iG/k3w/xjfy+xDcKifgS8SXiS8SXiC8RXyK+RHwfivgujj87PDhe3D7H EM41rFhLcj8ibXVsx0hbHac93hYgaTgZFou8e6CqS2uxGouPj/caiw96odaea2nG4rckXL2mjaec dMRscN+o9VrdX3nTbXX/6vzlf9OXD7O6P8SOhkUTlScqT1SeqDxReaLyROW3k8q372UoO33ddfsE xcj6baGg9O95GwXll9pKQR385NspLM/8t9pSYXnVn2y9he3dVmGJxd9qa4XlVRu2V1AC3bZYUPIf YZsFZbtT74Nrm8eDBZavMmkQuuTv0TxdJHvbMDAs7ajEHh8Pe3UxBK6lt+e62qnYWCbQ63qBuZMh 8K02NIapDQHAqJvagEUMLkRrXAid1r4OCzdaUtEaE16ATSzvYZCqoY7NL060v1gxvMcFCwI0GR4d 77VgAejFenuxbsECLOFrNSO82mLO4ctvs7TkIyzW3j+yeVgldfo24+zV6dnRGxkjpBTb0T1iGTu2 9gpiccd9s6+uGpUFeh3PMtedOPBbE3xms3RkbB/i8C7tQxy5eo+ifu1DHFt6e7G+fcAyWnRCy8I3 Jy60LR06qonA0o62icAiBi+8dV5E7SZCedISjMxWbMu9vZUQRgd1IZ6FWNl1H6KTdcWdTp2s12eX yc+Th+lkDW1ap506WamTlTpZqZOVOlmpk5U6Wf90naytYL44fGOsaBdHUDVoVVNDD9sqbzUvbYql OnX0hHbUNc0U1tlDE/JJ8Pb56/yhCHnsESEnQk6EnAg5EXIi5ETIiZATISdCfr+E3HHQuG9chl7M AaYVh+sfAxEvp8Oy9sSr65zzER81/fHXae46TESSVbOpmNOHrYVO/z54dc7WlMbIW04PrG7yOnkv v0G4wCXOvrgATA5KntT8i7badVKKlwaP2QiIvXyhnjazCq+SCqCQ4WwGbhdlcgnVIEuqChnxbz/3 eXHWrMH3FJ/e73t6jGhECQIlCJQgUIJACQIlCJQgUILwd08QPvsMMGmGHI+GCVBpRf92RD4Al/ZE I4WI2lxwT/4nFQyEuzG1cgprbh3bs/bk8U583LUCIx93beeDsXZVkb3jYixM/ivbATgSUNzFWmGn Lvd772sf5QP+firynm4zDI9Gr25+96GvHS5q8NuMlzd3UnygTno3ok564uDEwYmDEwcnDk4cnDj4 356Dyz527XYwn92+HcxSIud1Cp/9NEfL+2keB9hyUk6TfTGzquIlMq5MqGrbVpaEGqkZ2L/8NIlE xvO9OTds+L9chEXMzRBc+1t2cnF83BTM8iq9FHyykSg5dPP/O/Ae2Zbj/UcjcFVU9bryR9MnCPET QPn50ZvDZ2f/EsIQo+9TCFK0H8t3JONkyGWUPgOXwbEl096ZO7vH8mowHKR580c9qMp3e9JPMUny d16Md5pvu7tP1MQydSYPn0duGZML184HZ69/ag4wWavkEea6aK8Ys18HQA32pNI6j5aGpmCmKXjS Bx9Q/+rbVfn55ap5eTuLkl0TANf7bCGzarRlseJm/UJnYHHVkn21rlpWQrj0ZfK1I1GYY/ZVU1Wn e03VWgIovkj8/uiUo3p4rSBc5tjrc9SvM3lgF6tFXTdfltrmZBWb1W+iC8d7zeAJfctS9tBx3S7M WCLQazq2ec5LELbBvNKtvBSGTvQx0AtdT+szJL290IOKo7fneRr0sESo1/RjM3rw00LvktfJaFSm +RhX2sj1PgZ+kadqCz7u9cIvMqAQ+ZYGPyzh6jUD/474iQcr4dcXvyRdTtMmAHsAKAjhIK+LKaF3 K3pR5K2gJxKxYPD02bPXQP6PD0+QaGw72A4uDFbszNMUgZloSgfz0QlYw7ttQ3QsHWsvLvbdPjCD XmCwp90QHcsEjl43dI0ARZYVtmfZ5mgGMhK24/XYYGnHV/6g43EPbEDPdfT2XF+LDZaJ9LpetAYb 39Fgo+YfI9nA0c0/xiIGH6I1PthOa+bw0g8s5lpGG7GHhkIVU55XVbYPHxRopOFHd9gy3vEeQ6iR 4a47S8ZeQK8g6BUEvYL4f3tX29w2boQ/V79CY3vKJBNZsSfJXK7DztCUYquhXk6Sm7qnHIemGFsX SmRFKnHuJv+9z2IpgaABnt3Jh06ru9gmnmexALgAiJcFud+C2G9B7Lcg9lsQ+y2I/4stiGoN8H+6 7I6v7lMX5qTOu1OaEfUGb4daknp7A+n0zEXgR8hgOhwZCjHYf2N//439/8Jv7CvTj78qkwws0JvW /DGBP9FPjgwzvTevXpwYZnryc6ePnw9J7fsPP+3nQ/v50H4+tJ8P7edD+/nQfj60nw/9z8yHaoao r05NQ1Rwr6tHJxRFFdk3Rj0/nJ7szvy6dGQbAnAAS8Igh0uTN2lPUOHTIPxEe2KNw8Nmq/Jf8/CQ YDdAZvi9/tcxJgGATdKNIPTDzz4dJJ/bWRqsw1a2WbWyJEbs7PT4h7KAL94jXieGX8Wr6/2b1cam jQ4motVn33WpXdgqgrq/iRTsreecT1iyimqkRyOtPHBzDI3wfTmvo1MMWKtXuUMUx0Ddj0f+Ubpo zJhi5TjlH+njMaePeRdFdztZetu8P4+prtqrpAyWXQnIiAon3Vw0FHlw6Khbk7rdpnuVSJM4rmJZ RMdn9KiPUme2he75+bYDfl7tYy0l2m3sx0kwr5QdPpCBeAk/J6MQ0FpFeX+/osNUWPnmehmBP2nh k2Mp34xbiqUhC69TLZ+B0Ma8XuSZL5YCwFbTRN+zSHT4+muq1cZTYhlDIVY5/9HHjD+GKx0hvj6o IyCfx1piEWtzjdqXpLmOWKc6Pds1Eh2nTQBrSJt8EWuZ5SLXKqLOO450zDKIQeoYXknSMYXXsp+H 2hIVTx0fP5pMUoPSxcKaRRhlmS5GFqQ6+Mtcp0e89l1HsF+MjsluYAItcRvMky9aJp+H9nyR0ZNN ZXhp0BAHxtaUhBcGdVF43c3MaI0tPovJt5mTUjlTXWeSlp1quIUx4iIJ89hEpgGWo0wkGWazDo3J csdqYLnnM7N5YOTwEyc3JpZ6ayNHDdZEbsJ1NDfc+o35/m1WRgYnbU3cl2BhKl90Z+gMzOWGW/Zy kWgj8aqqlqncKR4xmIdnzP/xII6axHVE/4I0pbsp4XlcDBgoUQWfK89TycAXDl3dohKBn3Rcg1R5 4Cyvolkstahwdl8cWPARuaygnFxVT3L9K42JtoJpkN8id6i+GH5Y7U22bos+vH29WLULHG431lZ8 DYM6YztYK8D7d/Yq+PKpjLmuHYYKMBrZllinVpTRZe6PnQEmsvY6WCHn92lanBnZ1BWlZTLEGIyK pmLcZ5ax6AYO+7b4XYaXwaeIfykDHYRQV27F4wVPeNtSvg5iqULFp1TqhUrvkpImym7zJIltMVhu c4CZoldIwpsvMMBvsI6uvfCw11T9pUR9A1hCjqYl84gKS4e7o0zOaaj7salgjTiHIEnBPBCguZ9P H2ZK5naK0RjSiFlm2174j4L5FNduxXNVlLrdj1Su+6joVRehJPmpsQxuFijgcm5bR33nvOf6br9j 3Zeg7Q8RtgsunsNe1Gb9j3FwY7fWhHObIEMfUwYZ4nbhdWzRIsIwE+0hnpfZQd+2FHq1bLZSqywy 6UKD2qayiJVwHZT3OvR5EqHj1nm+wGQmjFLxtSyYpCyGmSdKJkGqPjdxch3EPr9NwE8XsKOFlJst eOpGTWtmWVn7l+NnPzf/9GH25Oezznj6gX8/mz0lkH6egfGd1j+D1m8fthcvWm9I5Kg9O2nOTvGv nZIyy5g0an0ohvI+zaIw7tLk48cmUvqlSYqbR+1m8/fZwexkdvC8+QRa0xzf6Hrx7TknVIr185nb 6Z7DA/eDjC6vhJ6D2anUAvLPs1MoekCO6Vt+uhvWPH6GJI6F/uJFd3RmbXbyl/tal8Ed1VE/Rms4 xSfBX74k0mR66wDGPxDx6614YDJj1Y5lQ5osCaEZbEnGJGtuzWnIh9mkBzqbbm1BZmGzzmBYWHb2 CNuqauQ1ayR9p4q2GYzMVlYLUm/pA4OpYWtOTLE2m5vVJzHppul7trjjOQE14y2epn50Hc4XITVP xuZh7Jc+KC8JzZSZidvgc6SLok4SZKo02HgtjANtqH6SEuOC7Rkye+vCX3DLT+jf7Vafgzsxnx4A SLIK80VJN68++FVvdpLg1TvD8t2QXyCirN8Z5RuOK3ad0PX/Prnoet63Zvs2WUbt5Vd/g1WBNg/x szY9ROJ5kLZ4t7bNz9nlIsswnYHu9WbVDELRL7dOjt9YDaff6Y7OsBM88ZzJhQ37MuS/dbxJ17YO t+Hp+BJBCmG3+rvkAw9qqIMu8XeCvxn+Xk4vaHUfQREYusPB2++SXLDJE1qHZbVim/P7lIMUc5Vk 1X3nXfe7KaaBGluKhpsWjTetxtllz+v4jut2J7QbBDjZgZed3rSCnXXOysFOd3A1HCnIYIJDsQpy NTgfDy9HFYw2HsrQhaoZVWjaH3YUCHv2avisr4RhatLs9HuubW3RPnYRylL94aA3HY7LEJ2ILodH 2Cx+31GQ7liVwK5Kz71SoPHwH1eu4150y+i4+xYb7SriOVcqMHWHHTXWe6VgwvoK4DmjThXoqcDl uCLyk6riauAiy4qlphdjVGUFwbQCqtyuWgZsAmI7p4z8HU18OC6EXJfmKfQXrb0vyoaOcZnMeSwM QiyJ2xYfRUBYzmzoumBxfXU+ctCI39tWFN5CMzalBQG9nR5seAy9GYKeNx0OPSQTxzQNsBpd92LI kfjaR5aKqwHSXRXXU4GSbwuEaXaDEHkzCLw3wF6t5/kdZ+pQI+QwmmFr2Xz98qUUwH08x25yWUaS Exczr6mBm4LbRZft/OhJMXHEHOepOLOBQr4bn73cdWcIvNoFqGHIAFpFKbC7l4CGZ38Tl8zWnz9j Ka5W8pru8k7F2N1eEozsPxHZf4rs50nKmxiYFTxt45nJVvEGPqLESCxDgKubzOu0nMUp7ZNzO/aw s+ztxNAlil2/79ItoksUuw9QO+xcet2JTGbIrd4v3UJkrnPZR1Wh6c5mmQpEVJYElx4chTpdUZFl yN/W9D4w4QfFpkIv0HXooYjMqUzhawSGfM5OS2QRh+ojRcRBrzb+nb6wGux+BXDrfgWo6rlFBSi7 j1FYdf1iRHEjK0NFxhhCo5x0yYdCdKU/AsK9OusxS7dNNmMAniOSL9YoLF6ksBoTZyLtiu18n2wr rrnDE9O96yC7BUI93rZz92mQAd8txKsyQ+QS/WuJOe9z25CIGioMr2RYZbxOhYDLCddOCVWqCqPc LfuoBshsGa3mCH0zdqVd77LTVVCdSoBqZMqKck+useHbiuFNWZbQ3JueVCSeFjIoFosssVpkNaae bBWycoo2ZTXe91ATHLfndwfOmddFKRnb3jyJr5KCIavvxKC8oMalPozXrJxx6bqEu668Lnp+CRRt VALVSseoWkSs4vgfA0wCotR1t8PVKsyj1kOGCw8A2youGI0xdKNdgHmS49nE2L82SQ45DmCcSv2W GPh+o69i4/XlzYOjI+DoKQ9YaLNSxe4gZDXQFiBCMDZlQ0yA4bZw960NGJzYjbd0K1REyp14axsM 000hv0USsPejfcaiVrIGs0Ey9GrwIg/b5LHvskbhS1myrcFwgOc4LR3rs8SczJEIyQwxUMkPg2p2 iltfydHOINSvVzju6uWz1bYe8+go4rWoPyLWzzbXIoGdPPDFtc5KgAVHoJZnCjI0nUIyebVYn2lm swxWFRgI4E9A/dS2xAWW0PB0o4n1XN4hXmiTN4fji6zn1eKCZa9kP0ejyeCeshSrFbjtz+/wv9XI DJWRcLBUJ+a6QmDBBvTXjOZOFSrKUXpebzXUGmZlveGwWnMYqtYdhiu1pzxEeWA9sHgWXp1/Kx5C jFTn3DWeV/e9aGucXutdXk0OrwZ3V5NLrsHh1+Aba/CMrfPHqvHyqvHx0nraGn3JjB5fZidovVeg 3ofQ6HRocvw1uf2anH71Lr9m3OixXutwqfMf1HsPah2NDZ6BJu9Po0+gwV3Z5KxsdBLVu4iaPJtN fvcmT0i9t/MjiVrc7DRtctyt8Yg2e1nX+FjXOFHXuFDXO1CbvGofz1Ej+0+4qfN4Rt5jsyO2yQ27 njL6Z5tcUc1+tuazE0Z/bo039yNwpej1B3cecmznIYd2HnRk5yEnkv74PFLtsSfTGSzzOaqas1k1 J7NqHckf5kb+GCdy/YkdE1w+wkZuK4D+DVBLAQIUABQAAAAIAMiMFDen4FoKJzMAAHMdAgAKAAAA AAAAAAAAIAAAAAAAAABjb25maWcubG9nUEsFBgAAAAABAAEAOAAAAE8zAAAAAA== ----------------3f8620ff6596fbde5a10880e48d84784--

1 0

Re: (ITS#5098) No Internationalization for certain attributes
by h.b.furuseth＠usit.uio.no 20 Aug '07

20 Aug '07

Heh. Looks like I should look up an ITS on www before replying, not just reply to what arrives in mail... -- Hallvard

1 0

Re: (ITS#5098) No Internationalization for certain attributes
by h.b.furuseth＠usit.uio.no 20 Aug '07

20 Aug '07

binoy(a)cordys.com writes: > mail attribute has the following syntax. > IA5String (OID=1.3.6.1.4.1.1466.115.121.1.26) IA5 (almost ASCII) (...) > This is why you cannot give non-ascii characters. Yes. It's an attribute standardized with that definition (derived from RFC 1274), and OpenLDAP follows the standard. > It is a bug. A design bug, perhaps, but not an OpenLDAP bug. This ITS will be closed. These attributes were designed quite a while ago by Europeans and Americans who clearly didn't pay too much attention to the rest of the world, but then it was before the age of computer internationalization. About 'mail', I'm not sure what sense 8-bit values would make since since SMTP could rewrite it to 7-bit. I could not send e-mail to an 8-bit address, but maybe it works where you live. OTOH, there is some standard for how to represent 8-bit domain names in ASCII. Maybe there is for 8-bit addresses too. telephoneNumber and facsimileTelephoneNumber are supposed to contain numbers in a 7-bit international format, E.123. It's irritating that one cannot include 8-bit comments along with such a number, but that's the standardized definition. Another and more irritating 7-bit attribute is 'gecos' from RFC 2307 (nis.schema in OpenLDAP). There is a draft revision of this one ("rfc2307bis") which I think revises it to 8-bit, but I don't know the status of that draft. -- Regards, Hallvard

1 0

(ITS#5099) openldap-2.3.37 configure can not find openssl/ssl.h
by y.le.ny＠ifrance.com 20 Aug '07

20 Aug '07

Full_Name: Yannnick LE NY Version: 2.3.37 OS: Sun Solaris 8 Sparc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.54.193.53) Hello, I found nothing for my problem here : http://www.openldap.org/faq Now, I'm trying to compile openldap-2.3.37 on Sun Solaris 8 / Sparc and the tools * gcc-3.4.6 * make 3.80 * autoconf 2.60 * automake 1.10 * pkgconfig 0.20 * m4 1.4.7 * mm 1.4.2 from www.sunfreeware.com, but I can not have a good configuration with SSL and SASL support in OpenLdap. I have : LD_LIBRARY_PATH=/opt/cyrus-sasl-1.5.28/lib:/opt/openssl-0.9.8e/lib:/opt/zlib-1.2.3/lib:/usr/local/lib/sparcv9:/usr/local/lib:/usr/lib:/usr/ccs/lib:. I use this parameters for configure : CFLAGS="-O3 -mcpu=ultrasparc -mtune=ultrasparc " \ CC=gcc CXX=gcc \ CXXFLAGS="-O3 -mcpu=ultrasparc -mtune=ultrasparc" \ CPPFLAGS="-I/opt/openssl-0.9.8e/include \ -I/opt/cyrus-sasl-1.5.28/include" \ LDFLAGS="-L/opt/openssl-0.9.8e/lib \ -L/opt/cyrus-sasl-1.5.28/lib" \ ./configure \ --prefix=/opt/openldap-2.3.37 \ --disable-slapd \ --disable-slurpd \ --with-tls \ --with-cyrus-sasl \ --with-threads \ --enable-shared --disable-static \ --with-pic Configure stop with this error : ...... checking for sys/un.h... yes checking openssl/ssl.h usability... no checking openssl/ssl.h presence... no checking for openssl/ssl.h... no configure: error: Could not locate TLS/SSL package With CPPFLAGS flags, I say where to find ssl.h but configure maybe don't use it. Please can you add support in configure file for the parameters: --with-tls=DIR --with-cyrus-sasl=DIR It will help the configure file to find libraries and headers in paths that are not standard. Thanks to help to resolve this problem.

1 0

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_01C7E31B.ACD2D040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 mail attribute has the following syntax. IA5String (OID=3D1.3.6.1.4.1.1466.115.121.1.26) IA5 (almost ASCII) <http://= www.zytrax.com/tech/ia5.html> character set (7-bit). Does NOT allow extend= ed characters e.g. =E9, =D8, =E5 etc. =20 This is why you cannot give non-ascii characters. It is a bug. =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_01C7E31B.ACD2D040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1"> <meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)"> <style>  </style> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple> <div class=3DSection1> Hi,   mail attribute has the following syntax. IA5String (OID=3D1.3.6.1.4.1.1466.115.121.1.26) <a href=3D"http://www.zytrax.com/tech/ia5.html" title=3D"">IA5 (almost ASCII)<= /a> character set (7-bit). Does = NOT allow extended characters e.g. =E9, =D8, =E5 etc.   This is why you cannot give non-ascii characters. It is a bug.   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_01C7E31B.ACD2D040--

1 0

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

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

16 Aug '07

Hi, oh my god what have i started here. Please don't try to convince me that standards are important and slapd pricecly implents RFC 2696, i was already convinced of that before i started the discussion. Anyway i like to resond to Howard Chu because he mentioned something dangerous and wrong regarding Active Directory (somewhat of topic here) but i like to avaoid people following his suggestion: Howard Chu <hyc(a)symas.com> wrote: >> Here is why i believe others might run into the same issue. If you need >> to create a ldap client dealing with big search results for various LDAP >> directories you had to use 1.2.840.113556.1.4.319 even if you are only >> interested in collecting the entire result otherwise you would fail with >> Active Directory. > >Nonsense. You simply ask your AD administrator to raise the default sizelimit, >the same way you would ask an OpenLDAP administrator to do the same thing. Well about 6 years ago when i first noticed this problem, i asked Microsoft about that limit and yes you can use ntdsutil.exe to set MaxPageSize to a higher limit: http://support.microsoft.com/kb/315071/en-us But it is strongly recommend to not change it!!!! 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. In 2001 SAP's IT set MaxPageSize=10000 for a few weeks as a temporary workaround until i was able to provide a real solution. That was a long time ago and today SAP's and probably most other companies Active Directories are running with default values. 1.2.840.113556.1.4.319 and MaxPageSize had not been invented to make our life more difficult. A good article about it is e.g. http://searchwinit.techtarget.com/tip/0,289483,sid1_gci1265206,00.html. I like to close with Gary Olsen's conclusion "The best practice for setting MaxPageSize is to leave it alone." Best regards Randolf

1 0

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

16 Aug '07

hyc(a)symas.com writes: >> The back-bdb behavior sounds right: It should remain possible to have >> the rootdn's password in an entry instead of in slapd.conf. Among other >> things, if the site has routines for regular password changes and "your >> password is getting old" warnings, those will then cover rootdn as well. > > (But aging out the administrator's password is a good way to lock > yourself out of your system. Sure, so it depends on just how central that password is. But if I've ignored a "your password is getting too old" warning for an admin user and it gets disabled I've screwed up anyway, I prefer to set things up to err on the side of caution. Though if it's even hard to log in to the server machine and fix things there, I'd be in trouble. > Note that ppolicy always lets the rootdn > past all policy checks for this reason.) Actually I've never used ppolicy, so I was thinking of our site's automatic emails when we need to change our passwords. >> OTOH if such an entry and rootpw both exist, I think it's a bug to >> accept both passwords. I think an existing rootpw should override the >> entry's password, that's safest and least surprising (if the admin sets >> rootpw and someone else manages to create an entry with dn: <rootdn>). > > I disagree; this behavior has existed for a long time and there are probably > people out there relying on it. Good point. I would still like to get rid of it though. Even if it takes an extra slapd.conf keyword. > This isn't much different from the fact that > userPassword itself is multivalued. I seem to recall this behavior being > documented somewhere, can't find the reference at the moment. I disagree - the difference is that rootpw vs. userPassword are stored in different places and different people can modify or create them. The rootpw doc in slapd.conf(5) looks misleading to me - at least it's easy to read it differently from how it works. I'm getting a deja vu feeling here, but I'm not sure from which discussion... >> A few icky issues: >> >> - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside >> the database's DIT, it would be possible to create such an entry with >> a password. We could advise people to use a DN outside the database >> suffix in this case, and/or accept 'rootpw' with no parameter as >> explicitly refusing Simple Bind with the rootdn. > > I don't think these cases merit any special consideration. OK. Well, I might do something more general to the doc which touches on it anyway if I think of a better way to write it. >> - back-null's "bind on" (accept Simple Bind with any password). >> Maybe in this case it's best to treat rootdn without rootpw as >> "reject simple bind as rootdn", like your patch does. > > If "bind on" means "accept Simple Bind with any password" then rootpw > should be irrelevant here. Of course, for back-null the rootdn itself is > pretty meaningless. I looked cross-eyed at that code. I meant bind off. Nevermind. -- Hallvard

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by ando＠sys-net.it 16 Aug '07

16 Aug '07

>> The back-bdb behavior sounds right: It should remain possible to have >> the rootdn's password in an entry instead of in slapd.conf. Among other >> things, if the site has routines for regular password changes and "your >> password is getting old" warnings, those will then cover rootdn as well. > > (But aging out the administrator's password is a good way to lock yourself > out > of your system. Note that ppolicy always lets the rootdn past all policy > checks > for this reason.) > >> OTOH if such an entry and rootpw both exist, I think it's a bug to >> accept both passwords. I think an existing rootpw should override the >> entry's password, that's safest and least surprising (if the admin sets >> rootpw and someone else manages to create an entry with dn: <rootdn>). > > I disagree; this behavior has existed for a long time and there are > probably > people out there relying on it. This isn't much different from the fact > that > userPassword itself is multivalued. I seem to recall this behavior being > documented somewhere, can't find the reference at the moment. In any case, I see this as a bug rather than a feature. The rootdn should be a special identity, which in many cases is only used for internal purposes. If the rootdn is outside the scope of the database, then it's not going to impact that database's be_bind(); if it's inside and it doesn't have a rootpw, then it might make sense that an entry with that DN exists, so that setting the rootpw could represent a means to workaround forgetting the entry's password or database corruptions. But checking both really sounds a bit too cumbersome. The we should allow multiple rootpw values... It's another question whether we should preserve or not this behavior for backward compatibility; in that case, all we need to do is handle the non-success, non-continue case in the switch and let it pass thru. But I'd require this at least to be explicitly enabled. >> A few icky issues: >> >> - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside >> the database's DIT, it would be possible to create such an entry with >> a password. We could advise people to use a DN outside the database >> suffix in this case, and/or accept 'rootpw' with no parameter as >> explicitly refusing Simple Bind with the rootdn. > > I don't think these cases merit any special consideration. I disagree. They sound academic, but they could pose a threat. I don't mean the code should obnoxiously check for this, but the possibility should be documented. The "right" solution would be to protect the identity of the rootdn with ACLs, so that regular users cannot add/modify it. >> - back-null's "bind on" (accept Simple Bind with any password). >> Maybe in this case it's best to treat rootdn without rootpw as >> "reject simple bind as rootdn", like your patch does. > > If "bind on" means "accept Simple Bind with any password" then rootpw > should be > irrelevant here. Of course, for back-null the rootdn itself is pretty > meaningless. Yes. The idea is to provide a simple means to allow binding with some identity without the need to configure anything special - that's the role of back-null, basically. What I essentially did was to take all backends that implement BI_op_bind and add the possibility to exploit the rootdn, which is allowed by the configuration anyway. I think this is better than letting people define rootdn/rootpw in the configuration and not using it. 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

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by quanah＠zimbra.com 16 Aug '07

16 Aug '07

--On Thursday, August 16, 2007 12:37 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > A few icky issues: > > - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside > the database's DIT, it would be possible to create such an entry with > a password. We could advise people to use a DN outside the database > suffix in this case, and/or accept 'rootpw' with no parameter as > explicitly refusing Simple Bind with the rootdn. Or in the case of SASL/GSSAPI, there can be a straight SASL rewrite to an internal DN for the rootdn as well. There is no requirement for the rootdn to have to have a rootpw associated with it, and there needn't be. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by hyc＠symas.com 16 Aug '07

16 Aug '07

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> Fixed in HEAD. Now all backends honor rootdn bind (with slight >> variations; see back-null) through a common interface; in some cases, >> it's a blind fix (shell, perl, passwd). I think I also fixed an >> inconsistency in back-bdb: as far as I understand, a bind with rootdn >> and incorrect rootdn password, or in case rootpw was null, originally >> passed through, probably either by mistake or to check if an analogous >> identity were defined in the database. I consider this an >> inconsistency, but please review. > > The back-bdb behavior sounds right: It should remain possible to have > the rootdn's password in an entry instead of in slapd.conf. Among other > things, if the site has routines for regular password changes and "your > password is getting old" warnings, those will then cover rootdn as well. (But aging out the administrator's password is a good way to lock yourself out of your system. Note that ppolicy always lets the rootdn past all policy checks for this reason.) > OTOH if such an entry and rootpw both exist, I think it's a bug to > accept both passwords. I think an existing rootpw should override the > entry's password, that's safest and least surprising (if the admin sets > rootpw and someone else manages to create an entry with dn: <rootdn>). I disagree; this behavior has existed for a long time and there are probably people out there relying on it. This isn't much different from the fact that userPassword itself is multivalued. I seem to recall this behavior being documented somewhere, can't find the reference at the moment. > A few icky issues: > > - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside > the database's DIT, it would be possible to create such an entry with > a password. We could advise people to use a DN outside the database > suffix in this case, and/or accept 'rootpw' with no parameter as > explicitly refusing Simple Bind with the rootdn. I don't think these cases merit any special consideration. > - back-null's "bind on" (accept Simple Bind with any password). > Maybe in this case it's best to treat rootdn without rootpw as > "reject simple bind as rootdn", like your patch does. If "bind on" means "accept Simple Bind with any password" then rootpw should be irrelevant here. Of course, for back-null the rootdn itself is pretty meaningless. -- -- 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

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

h.b.furuseth(a)usit.uio.no wrote: > That said, pretending that Microsoft does not exist isn't always a > winning strategy, so it might make sense to implement a "relaxed" mode > which accepts common ways to break the standard. But I don't think it > should be turned on by default. We don't pretend Microsoft doesn't exist. But we *do* expect them to mean what they say; since 3 Microsoft employees worked on RFC2696 you would sort of expect them to get it right. -- -- 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

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: > Hi, > =20 > thanks for your replies. Anyway i did not opened this message to discuss > who implented RFC 2696 correctly and who not. The point is something > else: The point is that there is a specific definition of the protocol. When vendors implement the protocol incorrectly, interoperability suffers. The fix for those interoperability problems is to take steps to ensure that vendors don't deviate from the published specifications. Likewise, application developers must pay attention to the published specs and write compliant code. Otherwise the entire concept of published standards is meaningless. > Here is why i believe others might run into the same issue. If you need > to create a ldap client dealing with big search results for various LDAP > directories you had to use 1.2.840.113556.1.4.319 even if you are only > interested in collecting the entire result otherwise you would fail with > Active Directory. Nonsense. You simply ask your AD administrator to raise the default sizelimit, the same way you would ask an OpenLDAP administrator to do the same thing. > I am not interested in discussing who is right and who is wrong, i am > just interested in making as much as possible working together in the > real world with as little as possible customer pain. In the real world, if you ignore the specs, your programs break. If you adhere to the specs, your programs keep working. What you're asking for is the equivalent of this: "My Microsoft building has a nail sticking out on the floor and I keep tripping over it when I walk by. Your OpenLDAP building is missing this nail; please pull a nail out so I can trip over it the same way." -- -- 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

Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by h.b.furuseth＠usit.uio.no 16 Aug '07

16 Aug '07

randolf.werner(a)sap.com writes: > Active Directory. You look at the ldap_create_page_control API spec > (developers oftern use API specs and not protocol RFCs) and notice page > size to be an usinged integer. Since you are not really interested in > pages you specify the largest possible value 2**32-1. So that API spec is bogus, it should have specified the range. Which data type is being used is not relevant to what the protocol accepts, in particular since the width of data types sometimes change. E.g. if you move from a 32-bit to a 64-bit host. > I am not interested in discussing who is right and who is wrong, i am > just interested in making as much as possible working together in the > real world with as little as possible customer pain. Notice however that your first problem happened because AD breaks the standard, and your second problem because you rewrote it by bogus Microsoft documentation and it worked because of another way AD breaks the standard. (Though less seriously in the second case, it follows the "be liberal in what you accept" way.) If OpenLDAP is changed to accept wider limits, it might also encourage more people to write bogus code like you did. OpenLDAP has been going in the other direction over the years, doing ever more strict error checking. That said, pretending that Microsoft does not exist isn't always a winning strategy, so it might make sense to implement a "relaxed" mode which accepts common ways to break the standard. But I don't think it should be turned on by default. > Therefore i am almost 100% sure Active Directory will not break > existing clients by using signed instead of unsigned integer page size > just to be more RFC 2696 compliant. In addition to fixing the doc, they they could fix that in API by reducing a passed value >= 2**31 to the max valid value. Not that they seem to care much about standards anyway. One note - I'm curious why you did not use page size 0, which the Microsoft API pages you posted say overrides such page sizes. Though maybe I misunderstood and that doesn't actually help. -- Regards, Hallvard

1 0

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

16 Aug '07

Pierangelo Masarati writes: > Fixed in HEAD. Now all backends honor rootdn bind (with slight > variations; see back-null) through a common interface; in some cases, > it's a blind fix (shell, perl, passwd). I think I also fixed an > inconsistency in back-bdb: as far as I understand, a bind with rootdn > and incorrect rootdn password, or in case rootpw was null, originally > passed through, probably either by mistake or to check if an analogous > identity were defined in the database. I consider this an > inconsistency, but please review. The back-bdb behavior sounds right: It should remain possible to have the rootdn's password in an entry instead of in slapd.conf. Among other things, if the site has routines for regular password changes and "your password is getting old" warnings, those will then cover rootdn as well. Also it matches better the behavior if you Bind with a DN in one database, which is the rootdn of another database. The Bind operation will work like a normal Bind since won't know that the DN is the rootdn of the second database. rootpw is a separate feature which can be convenient and which we in any case need so it is possible to bind as rootdn even with an empty database, or in backends which do not hold local entries. (Briefly: rootdn for authorization, rootpw+rootdn for authentication.) Anyway, that's why I suggested a be_rootpw_bind() rather than be_rootdn_bind() function, it reflects this better. (BTW, why a switch() statement to check its return value instead of just an if()?) OTOH if such an entry and rootpw both exist, I think it's a bug to accept both passwords. I think an existing rootpw should override the entry's password, that's safest and least surprising (if the admin sets rootpw and someone else manages to create an entry with dn: <rootdn>). A few icky issues: - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside the database's DIT, it would be possible to create such an entry with a password. We could advise people to use a DN outside the database suffix in this case, and/or accept 'rootpw' with no parameter as explicitly refusing Simple Bind with the rootdn. - back-null's "bind on" (accept Simple Bind with any password). Maybe in this case it's best to treat rootdn without rootpw as "reject simple bind as rootdn", like your patch does. I don't know if there are overlays which can also make it sensible to do that, or if we need to anticipate such overlays. retcode, maybe? -- Regards, Hallvard

1 0

(ITS#5093) slap_mods_opattrs() doesn't work with modrdn
by ando＠sys-net.it 16 Aug '07

16 Aug '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando I've noticed that in HEAD modifyTimestamp and entryCSN do not change over modrdn. The reason is subtle, because slap_mods_opattrs() expects to be called with Operation's o_request data for a modify and not for modrdn, which misses the rs_no_opattrs member. I've reworked things to better preserve modification consistency in the future. p.

1 0

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by ando＠sys-net.it 16 Aug '07

16 Aug '07

Fixed in HEAD. Now all backends honor rootdn bind (with slight variations; see back-null) through a common interface; in some cases, it's a blind fix (shell, perl, passwd). I think I also fixed an inconsistency in back-bdb: as far as I understand, a bind with rootdn and incorrect rootdn password, or in case rootpw was null, originally passed through, probably either by mistake or to check if an analogous identity were defined in the database. I consider this an inconsistency, but please review. 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

Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by ando＠sys-net.it 16 Aug '07

16 Aug '07

ghenry(a)suretecsystems.com wrote: > Don't you do this in test043: > > "# HACK: use the RootDN of the monitor database as UpdateDN so ACLs apply" exactly. 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

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

16 Aug '07

This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DFD5.8B035F66 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 thanks for your replies. Anyway i did not opened this message to discuss who implented RFC 2696 correctly and who not. The point is something else: =20 1) I tried to share my experience (and solution) with other LDAP application programmers, since i am pretty sure there are/will be more clients running into this issue (e.g. ldp.exe from Windows support tools seems to have the same problem when enabling 1.2.840.113556.1.4.319 / pages search type again slapd). 2) Try to point out how it can easily happen to write a client working with Active Directory but not with slapd and suggested an easy but perhaps not 100% RFC 2696 compliant slapd change. =20 Perhaps i should explain 2) a little bit more from my application develeopers point of view. Here is my rough application history: =20 a) In ~1999 we started building a LDAP V3 client for SAP that had to work on a very wide variety of OS platforms and as much as possible LDAP V3 compliant directories. b) It was first shipped in 2000/2001 and customers were happy. c) Data volume at customer side increazed and it stopped working for Active Directory customers. d) We learned about size limits, page size and the fact you simply have to use 1.2.840.113556.1.4.319 to get more than 1000 entries from Active Directroy. We implemented it and everybody was happy again. Implenting ldap_create_page_control for all OS platforms was not that trivial at that time. e) In ~2004 the first customer liked to use slapd. We noticed some minor issues (e.g. setting V3 protocol version explicitly) fixed it and once more everybody was happy. f) Yesterday a slapd 2.3.35 slapd customer reported a problem similar to e) ("Protocol Error"). So we analyzed it and fixed it again by reducing default page size to 2**31-1. =20 Here is why i believe others might run into the same issue. If you need to create a ldap client dealing with big search results for various LDAP directories you had to use 1.2.840.113556.1.4.319 even if you are only interested in collecting the entire result otherwise you would fail with Active Directory. You look at the ldap_create_page_control API spec (developers oftern use API specs and not protocol RFCs) and notice page size to be an usinged integer. Since you are not really interested in pages you specify the largest possible value 2**32-1. This way you end up with client working with Active Directory, all directories not supporting 1.2.840.113556.1.4.319 but not with slapd supporting 1.2.840.113556.1.4.319. =20 I am not interested in discussing who is right and who is wrong, i am just interested in making as much as possible working together in the real world with as little as possible customer pain. Therefore i am almost 100% sure Active Directory will not break existing clients by using signed instead of unsigned integer page size just to be more RFC 2696 compliant.On the other hand slapd has a chance to detect negavtive page sizes and assume some reasonable page size in that situation instead of "Protocol Error" without breaking any existing client. For my customers it will not make much difference since the patch will be rolled out soon, but perhaps others can benefit. =20 Best regards Randolf =20 =20 ------_=_NextPart_001_01C7DFD5.8B035F66 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.3790.2920" name=3DGENERATOR></HEAD> <BODY> <DIV>Hi,</DIV> <DIV> </DIV> <DIV>thanks = for your=20 replies. Anyway i did not opened this message to discuss who implented = RFC 2696=20 correctly and who not.  The point is something=20 else:</DIV> <DIV> </DIV> <DIV>1) I = tried to share=20 my experience (and solution) with other LDAP application programmers, = since i am=20 pretty sure there are/will be more clients running into this issue (e.g. = ldp.exe=20 from Windows support tools seems to have the same problem when enabling=20 1.2.840.113556.1.4.319 / pages search type again = slapd).</DIV> <DIV>2) Try = to point out=20 how it can easily happen to write a client working with Active Directory = but not=20 with slapd and suggested an easy but perhaps not 100% RFC 2696 compliant = slapd=20 change.</DIV> <DIV> </DIV> <DIV>Perhaps i should=20 explain 2) a little bit more from my application develeopers point of = view. Here=20 is my rough application history:</DIV> <DIV> </DIV> <DIV>a) In = ~1999 we=20 started building a LDAP V3 client for SAP that had to work on a very = wide=20 variety of OS platforms and as much as possible LDAP V3 compliant=20 directories.</DIV> <DIV>b) It = was first=20 shipped in 2000/2001 and customers were happy.</DIV> <DIV>c) = Data volume at=20 customer side increazed and it stopped working for Active Directory=20 customers.</DIV> <DIV>d) We = learned about=20 size limits, page size and the fact you simply have to use=20 1.2.840.113556.1.4.319  to get more than 1000 entries from Active=20 Directroy. We implemented it and everybody was happy again. Implenting=20 ldap_create_page_control for all OS platforms was not that trivial at = that=20 time.</DIV> <DIV>e) In = ~2004 the=20 first customer liked to use slapd. We noticed some minor issues (e.g. = setting V3=20 protocol version explicitly) fixed it and once more everybody was=20 happy.</DIV> <DIV>f) = Yesterday a slapd=20 2.3.35 slapd customer reported a problem similar to e) ("Protocol = Error"). So we=20 analyzed it and fixed it again by reducing default page size to=20 2**31-1.</DIV> <DIV> </DIV> <DIV>Here = is why i=20 believe others might run into the same issue. If y<SPAN=20 class=3D021122006-16082007>ou need to create = a ldap client=20 dealing with big search results for various LDAP directories you had to = use=20 1.2.840.113556.1.4.319 even if you are only interested in collecting the = entire=20 result otherwise you would fail with Active Directory. You look at the=20 ldap_create_page_control API spec (developers oftern use API specs and = not=20 protocol RFCs) and notice page size to be an usinged integer. Since you = are not=20 really interested in pages you specify the largest possible value = 2**32-1.=20 This way you end up with client working with Active Directory, all=20 directories not supporting 1.2.840.113556.1.4.319 but not with = slapd=20 supporting 1.2.840.113556.1.4.319.</DIV> <DIV> </DIV> <DIV>I am = not interested=20 in discussing who is right and who is wrong, i am just interested in = making as=20 much as possible working together in the real world with as little as = possible=20 customer pain. Therefore i am almost 100% sure Active Directory will not = break=20 existing clients by using signed instead of unsigned integer page size = just to=20 be more RFC 2696 compliant.On the other hand slapd has a chance to = detect=20 negavtive page sizes and assume some reasonable page size in that = situation=20 instead of "Protocol Error" without breaking any existing client. For my = customers it will not make much difference since the patch will be = rolled=20 out soon, but perhaps others can benefit.</DIV> <DIV> </DIV> <DIV>Best=20 regards</DIV> <DIV>   =20 Randolf</DIV> <DIV> </DIV> <DIV> </DIV></BODY></HTML> ------_=_NextPart_001_01C7DFD5.8B035F66--

1 0

Re: (ITS#4627) back-ldif issues
by ando＠sys-net.it 15 Aug '07

15 Aug '07

> Yes, we require POSIX semantics here. rename() unlinks the target > atomically; In fact, that was my understanding of rename(2). >>>> .inum should be signed, or should be read with strtoul instead of >>>> strtol. >>> strtoul(3) used > > I think strtoul() here is a mistake, and we've fixed/refixed this point a > couple times already. Remember that frontendDB has an index of {-1} in the > config tree. Right. Then we need to use a signed integer. 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

Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by ando＠sys-net.it 15 Aug '07

15 Aug '07

> randolf.werner(a)sap.com wrote: >> Full_Name: Randolf Werner >> Version: 2.3.35 >> OS: Windows XP >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (155.56.68.221) >> >> >> Hi, >> i just have found the following compatibilty issue when using the >> 1.2.840.113556.1.4.319 control (http://www.ietf.org/rfc/rfc2696.txt) >> supported >> by slapd. According to Microsoft and IBM LDAP API >> ldap_create_page_control >> >> http://msdn2.microsoft.com/en-us/library/aa366547.aspx >> http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis… >> >> the page size parameter should be an 32 Bit unsigned integer, however >> the RFC >> specifies it as "(INTEGER (0..maxInt)". Therefore our LDAP client uses >> 2**32-1 >> as default page size value. This works fine with Microsoft Active >> Directroy for >> many years but fails with "Protocol Error" (Error 2) when using slapd. >> Our >> workaround is to use 2**31-1 as default value in our client. I am not >> sure which >> implementation is correct, anyway it is a compatibility issue for ldap >> clients >> and might be "fixed" to improve compatibility. > > I suggest you file bug reports with Microsoft and IBM to fix their broken > implementations then. RFC4511 clearly defines maxInt to be 2^31-1. That > value > has not changed since RFC2251 either. Or, fix your clients so that they don't use pagedResults when not necessary. 2**31-1 is a pretty large number. 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

Re: (ITS#4627) back-ldif issues
by h.b.furuseth＠usit.uio.no 15 Aug '07

15 Aug '07

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> Not there yet... you create it in the current directory instead >> of in the ldif directory. >> >> Possibly it's best to create it in the top directory of the ldif >> database. That way, if a temp file is somehow created and not >> cleaned away, it's (a) in the easiest place to see and (b) won't >> prevent rmdir() if one tries to delete that database or whatever. > > I would use "rm -rf" to delete the DB, in which case (b) is a moot point. Sorry, I meant if one uses LDAP operations to delete a non-leaf entry. (I was thinking of a "cn=config/olcDatabase=.../" subtree.) >>> (...) >>>> .inum should be signed, or should be read with strtoul instead of >>>> strtol. >>> strtoul(3) used > > I think strtoul() here is a mistake, and we've fixed/refixed this point a > couple times already. Remember that frontendDB has an index of {-1} in the > config tree. Time to re-fix again and add a comment about that this time... Hm. It is read with strto(u)l but is int and not long. Maybe that's what I was talking about with what its type should be. -- Regards, Hallvard

1 0

Re: (ITS#4627) back-ldif issues
by hyc＠symas.com 15 Aug '07

15 Aug '07

h.b.furuseth(a)usit.uio.no wrote: > Possibly it's best to create it in the top directory of the ldif > database. That way, if a temp file is somehow created and not > cleaned away, it's (a) in the easiest place to see and (b) won't > prevent rmdir() if one tries to delete that database or whatever. > > I don't know if there are non-Unix OSes which need special system calls > to move file between directories though. Or for that matter, if they > allow rename() to replace an existing file, maybe unlink is needed > first. The code looks very Unixy already, so I assume a Unix emulation > is needed to run it anyway. I don't know how those work. For that matter, I think the temp file must be created in the same directory as the existing file. It's always possible that someone will mount a new filesystem somewhere in the hierarchy, and you cannot rename() across mountpoints. -- -- 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

Re: (ITS#4627) back-ldif issues
by hyc＠symas.com 15 Aug '07

15 Aug '07

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >>> Error handling: >>> >>> ldif_tool_entry_first() cannot return NOID. >> Dunno (untouched) > > Howard fixed. One remaining issue: ldif_tool_entry_next() increments > li->li_tool_current even when it returns NOID. Should it do that? Harmless, but stupid. Fixed now. > >> (...) >>> back-ldif overwrites files instead writing to a temp file and >>> renaming when complete. The current way corrupts entries if a >>> write fails halfway through, e.g. due to a full disk. Also the >>> file can be left truncated if internal slapd operations fail. >>> If the OS supports it, back-ldif should make a new file in the >>> same directory and rename to the old filename when complete. >> Fixed; now mkstemp(3) is used, and rename(2) only in case of success. > > Not there yet... you create it in the current directory instead > of in the ldif directory. > > Possibly it's best to create it in the top directory of the ldif > database. That way, if a temp file is somehow created and not > cleaned away, it's (a) in the easiest place to see and (b) won't > prevent rmdir() if one tries to delete that database or whatever. I would use "rm -rf" to delete the DB, in which case (b) is a moot point. > I don't know if there are non-Unix OSes which need special system calls > to move file between directories though. Or for that matter, if they > allow rename() to replace an existing file, maybe unlink is needed > first. The code looks very Unixy already, so I assume a Unix emulation > is needed to run it anyway. I don't know how those work. Yes, we require POSIX semantics here. rename() unlinks the target atomically; it would be a mistake to code this in a different manner. > Also there were some spew_entry() coding errors, rev 1.70 fixes them. > >> (...) >>> .inum should be signed, or should be read with strtoul instead of >>> strtol. >> strtoul(3) used I think strtoul() here is a mistake, and we've fixed/refixed this point a couple times already. Remember that frontendDB has an index of {-1} in the config tree. >>> I suppose it and cmp in the function should be ber_int_t, >>> since LDAP integers are typically 32-bit. >> Not sure what you mean. > > I don't remember. Maybe the number can end up being sent over the > protocol, and it's possible to create a filename with a long > max > ber_int_t so the wrong number will be sent? > -- -- 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

Re: (ITS#4627) back-ldif issues
by h.b.furuseth＠usit.uio.no 15 Aug '07

15 Aug '07

Pierangelo Masarati writes: >> Error handling: >> >> ldif_tool_entry_first() cannot return NOID. > > Dunno (untouched) Howard fixed. One remaining issue: ldif_tool_entry_next() increments li->li_tool_current even when it returns NOID. Should it do that? > (...) >> back-ldif overwrites files instead writing to a temp file and >> renaming when complete. The current way corrupts entries if a >> write fails halfway through, e.g. due to a full disk. Also the >> file can be left truncated if internal slapd operations fail. >> If the OS supports it, back-ldif should make a new file in the >> same directory and rename to the old filename when complete. > > Fixed; now mkstemp(3) is used, and rename(2) only in case of success. Not there yet... you create it in the current directory instead of in the ldif directory. Possibly it's best to create it in the top directory of the ldif database. That way, if a temp file is somehow created and not cleaned away, it's (a) in the easiest place to see and (b) won't prevent rmdir() if one tries to delete that database or whatever. I don't know if there are non-Unix OSes which need special system calls to move file between directories though. Or for that matter, if they allow rename() to replace an existing file, maybe unlink is needed first. The code looks very Unixy already, so I assume a Unix emulation is needed to run it anyway. I don't know how those work. Also there were some spew_entry() coding errors, rev 1.70 fixes them. > (...) >> .inum should be signed, or should be read with strtoul instead of >> strtol. > > strtoul(3) used > >> I suppose it and cmp in the function should be ber_int_t, >> since LDAP integers are typically 32-bit. > > Not sure what you mean. I don't remember. Maybe the number can end up being sent over the protocol, and it's possible to create a filename with a long > max ber_int_t so the wrong number will be sent? -- Hallvard

1 0

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

15 Aug '07

randolf.werner(a)sap.com wrote: > Full_Name: Randolf Werner > Version: 2.3.35 > OS: Windows XP > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (155.56.68.221) > > > Hi, > i just have found the following compatibilty issue when using the > 1.2.840.113556.1.4.319 control (http://www.ietf.org/rfc/rfc2696.txt) supported > by slapd. According to Microsoft and IBM LDAP API ldap_create_page_control > > http://msdn2.microsoft.com/en-us/library/aa366547.aspx > http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis… > > the page size parameter should be an 32 Bit unsigned integer, however the RFC > specifies it as "(INTEGER (0..maxInt)". Therefore our LDAP client uses 2**32-1 > as default page size value. This works fine with Microsoft Active Directroy for > many years but fails with "Protocol Error" (Error 2) when using slapd. Our > workaround is to use 2**31-1 as default value in our client. I am not sure which > implementation is correct, anyway it is a compatibility issue for ldap clients > and might be "fixed" to improve compatibility. I suggest you file bug reports with Microsoft and IBM to fix their broken implementations then. RFC4511 clearly defines maxInt to be 2^31-1. That value has not changed since RFC2251 either. -- -- 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

Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by kurt＠OpenLDAP.org 15 Aug '07

15 Aug '07

On Aug 15, 2007, at 2:21 PM, randolf.werner(a)sap.com wrote: > Full_Name: Randolf Werner > Version: 2.3.35 > OS: Windows XP > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (155.56.68.221) > > > Hi, > i just have found the following compatibilty issue when using the > 1.2.840.113556.1.4.319 control (http://www.ietf.org/rfc/ > rfc2696.txt) supported > by slapd. According to Microsoft and IBM LDAP API > ldap_create_page_control > > http://msdn2.microsoft.com/en-us/library/aa366547.aspx > http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp? > topic=/apis/ldap_create_page_control.htm > > the page size parameter should be an 32 Bit unsigned integer, > however the RFC > specifies it as "(INTEGER (0..maxInt)". Therefore our LDAP client > uses 2**32-1 > as default page size value. This works fine with Microsoft Active > Directroy for > many years but fails with "Protocol Error" (Error 2) when using > slapd. Our > workaround is to use 2**31-1 as default value in our client. I am > not sure which > implementation is correct, anyway it is a compatibility issue for > ldap clients > and might be "fixed" to improve compatibility. Given maxInt is defined in RFC 4511 as: maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- this doesn't appear to be a bug in OpenLDAP Software. -- Kurt

1 0

(ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by randolf.werner＠sap.com 15 Aug '07

15 Aug '07

Full_Name: Randolf Werner Version: 2.3.35 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.56.68.221) Hi, i just have found the following compatibilty issue when using the 1.2.840.113556.1.4.319 control (http://www.ietf.org/rfc/rfc2696.txt) supported by slapd. According to Microsoft and IBM LDAP API ldap_create_page_control http://msdn2.microsoft.com/en-us/library/aa366547.aspx http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/apis… the page size parameter should be an 32 Bit unsigned integer, however the RFC specifies it as "(INTEGER (0..maxInt)". Therefore our LDAP client uses 2**32-1 as default page size value. This works fine with Microsoft Active Directroy for many years but fails with "Protocol Error" (Error 2) when using slapd. Our workaround is to use 2**31-1 as default value in our client. I am not sure which implementation is correct, anyway it is a compatibility issue for ldap clients and might be "fixed" to improve compatibility. Best regards Randolf

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs