- openldap-bugs - openldap.org

Re: (ITS#6657) back-sql segfault in backsql_search
by timo.teras＠iki.fi 13 Jun '11

13 Jun '11

ITS#6691 seems to be same issue. I have a patch to fix this. It's available at: http://git.alpinelinux.org/cgit/aports.git/plain/main/openldap/openldap-bac… - Timo

1 0

(ITS#6972) [PATCH] Autogroup double-free of LDAPURLDesc *lud in autogroup_add_group when the URL contains a filter with >1 attribute.
by gerry＠everythingsucks.co.uk 12 Jun '11

12 Jun '11

Full_Name: Gerry Calderhead Version: OpenLDAP 2.4.25 OS: Linux RHEL5.5 URL: http://uploading.com/files/ad3ecc7f/0001-Autogroup-double-free-of-LDAPURLDe… Submission from: (NULL) (80.238.1.135) We found this issue when we swapped from dynlist to autogroup. Dynlist happily supports pulling over multiple attributes (memberuid and member in our case). When we removed dynlist and added autogroup instead we got an immediate crash because a double-free was picked up by our C library. The code at fault is in autogroup_add_group in the case for was: "to much attributes" now: "too many (%d) attributes" where the lud was free'd then "goto cleanup" was called thus attempting to free it agan. Fix --- The bare-minimum change requried to stop the crash in this case is: File:autogroup.c Function: autogroup_add_group if ( i > 1 ) { Debug( LDAP_DEBUG_ANY, "autogroup_add_group: to much attributes specified in url <%s>\n", bv->bv_val, 0, 0); /* FIXME: error? */ ldap_free_urldesc( lud ); ch_free( agf ); + continue; } I've taken the opportunity to sense-check the other error cases here and hence made the error reporting slightly more useful and eliminated the goto. The git-format-patch, containing the fix above and the clean-up I mentioned is available here: http://uploading.com/files/ad3ecc7f/0001-Autogroup-double-free-of-LDAPURLDe… sha1sum 313f55d01f37a48c5c29ea5232e6343039e6e956 0001-Autogroup-double-free-of-LDAPURLDesc-lud-in-autogrou.patch Public Domain Notice -------------------- I, Gerry Calderhead, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#6971) Incorrect configure option in documentation
by crhea＠mayo.edu 11 Jun '11

11 Jun '11

Full_Name: Cris Rhea Version: 2.4.25 OS: Linux/CentOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.176.151.29) http://www.openldap.org/doc/admin24/install.html#TCP%20Wrappers Sections 4.2.6 and 4.3 mention using "--with-wrappers" to enable TCP Wrappers. This option does not cause "configure" to fail, but instead, silently does nothing. The correct option is "--enable-wrappers". This is also a minor security bug as people might think their systems have TCP Wrapper restrictions, but unless someone tests it, they won't realize it isn't working.

1 0

Re: (ITS#6970) OpenLDAP 2.4.25 MemberOf + AutoGroup user has stale "memberof" attributes for target group after removal from trigger group
by gerry＠everythingsucks.co.uk 11 Jun '11

11 Jun '11

--001485f8123ed53b6404a5759323 Content-Type: text/plain; charset=ISO-8859-1 Note the "Analysis" section is a copy/paste of the comment from the code. When it says "this response function" it means the function: autogroup_response. G On 11 June 2011 21:24, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6970. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6970) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6970) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6970 > > Please remember to retain your issue tracking number (ITS#6970) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --001485f8123ed53b6404a5759323 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Note the "Analysis" section is a copy/paste of the comment from t= he code. When it says "this response function" it means the fu= nction: autogroup_response. G <div class=3D"gmail_quote">On 11 Ju= ne 2011 21:24, <<a href=3D"mailto:openldap-its@openld= ap.org">openldap-its(a)openldap.org</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. =A0Your report has been assigned the tracking number ITS#6970. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. =A0They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. =A0Note that any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#6970) in the subject will automatically be attached to the issue report. =A0 =A0 =A0 =A0mailto:<a href=3D"mailto:openldap-its@openldap.org">openlda= p-its(a)openldap.org</a>?subject=3D(ITS#6970) You may follow the progress of this report by loading the following URL in a web browser: =A0 =A0<a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D6970" tar= get=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D6970</a> Please remember to retain your issue tracking number (ITS#6970) on any further messages you send to us regarding this report. =A0If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =A0 =A0 =A0 =A0<a href=3D"http://www.OpenLDAP.org/support/" target=3D"_bla= nk">http://www.OpenLDAP.org/support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. </blockquote></div> --001485f8123ed53b6404a5759323--

1 0

(ITS#6970) OpenLDAP 2.4.25 MemberOf + AutoGroup user has stale "memberof" attributes for target group after removal from trigger group
by gerry＠everythingsucks.co.uk 11 Jun '11

11 Jun '11

Full_Name: Gerry Calderhead Version: OpenLDAP 2.4.25 OS: Linux RHEL5.5 URL: http://uploading.com/files/529d29ce/0001-MemberOf-AutoGroup-together-can-le… Submission from: (NULL) (80.238.1.135) What we're trying to do ----------------------- We are using OpenLDAP + GOsa to manage users who have access to an extranet. There are a set of tools on the extranet, let's call then VCS, Bugs, Wiki. The extranet is accessibly by third-parties. We want to delegate some admin to staff in the third parties. The structure we want to use is: Multiple organisations Each organisation has a group per tool, e.g. VCS_access, Bugs_Access, Wiki_Access. Organisation admins can add people to their own groups. We then want to aggregate all people with access to those tools into some top level groups, e.g. all_VCS_access = org1.VCS_access + org2.VCS_access all_Bugs_access = org1.Bugs_access + org2.Bugs_access all_Wiki_access = org1.Wiki_access + org2.Wiki_access It's important to us that when people are added/removed to the organisational groups that the group 'member' attributes and the user's 'memberof' attributes are correct and consistent as these for the basis for our access management. Observed Problem ----------------- If you add a user to a monitored group they are consistently added to the target group. You can now search for them using a memberof filter. If you then remove the user from a monitored group they are consistently removed from the target group. However if you then search for members of the target group using a memberOf filter the removed users always show up. 100% reproducible in our environment. Analysis -------- When using bother AutoGroup + MemberOf the "memberof" attributes are not always deleted when users are removed from a group. The approach this overlay takes to updating the target members list, when a member of a monitored list is removed, is to basically clear the membership and re-populate based on a search. Generally the Autogroup Entry requiring a refresh will be flagged in autogroup_modify_entry function. Within this response function we will then spot these flagged refreshes and will perform the deletes and searches to re-polulate the groups. So far, so simple. However, this response function is not necessarily executing in response context of the original modification (say of a "member") but could be in response to a different modification, specifically the addition of a "memberOf" attribute. i.e. it behaves asynchronously - refreshing the group sometime after the initial change. This is a problem when you wish to use MemberOf and AutoGroup together. 1. Admin removes a "member" of a group 2. AutoGroup spots the removal from a trigger group and flags a refresh on the AutoGroup Entry for the target group. 3. MemberOf overlay's _modify function is called, spots the removal of the "member" and updates the "memberOf" attribute of the trigger group. 4. This response function is called in the context of "memberOf" update 5. We spot the flag on the AGE, and delete all "member"s from the target and initiate searches to re-populate. 6. The MemberOf overlay's _modify function is called in response to the "member" changes in the target group (5). 8. MemberOf's _modify function is guarded against recursion, and exits immediately without removing the "memberof" attributes from the users in the target group. 9. When the search completes all remaining "member"'s will be re-added to the target group. The users will have their "memberOf"'s updated but the chance to remove the dead "memberOf"'s is gone. These will now linger around in the DB. So, the simplest solution I can think of is that we do not make any changes in the context of a modification that may have originated from the MemberOf overlay and instead wait on the next opportunity to trigger the refreshes. In reality if the trigger for the refresh was a "member" change then the refresh will happen during the course of the corresponding _response's - just not on any which modify "memberof". Fix ---- Add the following lines at the start of autogroup_response() if ( op->o_tag == LDAP_REQ_MODIFY ) { Modifications *mz; for ( mz = op->orm_modlist; mz; mz = mz->sml_next ) { if ( mz->sml_mod.sm_desc == agi->agi_memberof_ad ) { Debug(LDAP_DEBUG_TRACE,"==> autogroup_response in context of 'memberof' modification, do nothing!\n", 0, 0, 0); return SLAP_CB_CONTINUE; } } } Full git-format-patch present at URL specified. sha1sum 0001-MemberOf-AutoGroup-together-can-leave-stale-memberof.patch 76c2cf268fff37c0cd744e7b3cfd0afa63d9e991 0001-MemberOf-AutoGroup-together-can-leave-stale-memberof.patch Public Domain Notice -------------------- I, Gerry Calderhead, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6892) Segfault in Syncprov overlay
by ghola＠rebelbase.com 10 Jun '11

10 Jun '11

> A patch to avoid this particular crash is now in git master. However, it's still not clear to me why it occurred. Can you get this info from gdb: > frame 1 > print *ss Thanks Howard, here is the info you requested: (gdb) bt #0 test_filter (op=0x40fff7f0, e=0x2aab116ab068, f=0x0) at filterentry.c:69 #1 0x00000000004db315 in syncprov_matchops (op=0x410001b0, opc=0xb096e0, saveit=1) at syncprov.c:1314 #2 0x00000000004db6b5 in syncprov_op_mod (op=0x410001b0, rs=<value optimized out>) at syncprov.c:2124 #3 0x000000000047e62a in overlay_op_walk (op=0x410001b0, rs=0x40ffffc0, which=op_modify, oi=0x8d7ab0, on=0x8dc4f0) at backover.c:659 #4 0x000000000047ec07 in over_op_func (op=0x410001b0, rs=0x40ffffc0, which=op_modify) at backover.c:721 #5 0x000000000047404d in syncrepl_updateCookie (si=0x8d74d0, op=0x410001b0, syncCookie=0x41000b20) at syncrepl.c:3292 #6 0x0000000000478462 in do_syncrep2 (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1097 #7 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1455 #8 0x00000000004ec5ec in ldap_int_thread_pool_wrapper (xpool=0x84daf0) at tpool.c:685 #9 0x000000301b20673d in start_thread (arg=<value optimized out>) at pthread_create.c:301 #10 0x000000301aad44bd in clone () from /lib64/libc.so.6 (gdb) frame 1 #1 0x00000000004db315 in syncprov_matchops (op=0x410001b0, opc=0xb096e0, saveit=1) at syncprov.c:1314 1314 rc = test_filter( &op2, e, op2.ors_filter ); (gdb) print *ss $1 = {s_next = 0x2aab502177f0, s_base = {bv_len = 16, bv_val = 0x2aab730920e0 "dc=test12,dc=net"}, s_eid = 1, s_op = 0x230ea90, s_rid = 1, s_sid = -1, s_filterstr = {bv_len = 15, bv_val = 0x230f7d0 "(objectClass=*)"}, s_flags = 1, s_inuse = 1, s_res = 0x2aababca90f0, s_restail = 0x2aabc320d920, s_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}

1 0

(ITS#6969) Need option to show which TLS library is in use
by hyc＠OpenLDAP.org 10 Jun '11

10 Jun '11

Full_Name: Howard Chu Version: 2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc Now that OpenSSL is not the only TLS library that we support, app developers need a way to check which library is in use. libldap has the info, but due to an oversight it was not exposed. The LDAP_OPT_X_TLS_PACKAGE option has been added to retrieve the TLS implementation name. Currently it may be "OpenSSL", "GnuTLS", or "MozNSS".

1 0

Re: (ITS#6968) Glue objectclass created during Grouper provisioning
by hyc＠symas.com 10 Jun '11

10 Jun '11

Mark.Cairney(a)ed.ac.uk wrote: > Full_Name: Mark Cairney > Version: 2.4.25 > OS: RHEL 5.5 x64 > URL: ftp://ftp.ed.ac.uk/incoming/Mark-Cairney-110610.zip > Submission from: (NULL) (129.215.200.77) > > > During provisioning using Grouper (http://www.internet2.edu/grouper) to populate > a tree of ou and posixGroup objects it looks like the request to create a child > OU is being issued and granted. > This results in the creation of a "ghost" parent OU with the glue objectClass as > documented but syncrepl then constantly tries and fails to provision the ghost > OU to the other servers (as shown in alderlog.txt). Your ftp server is demanding authentication, can't download your file. > My cn=config is listed in cnconfig.txt for reference > > The issue can be reproduced by running Grouper's LDAP provisioner with Grouper > configured to produce a "bushy" structure and it may also be reproduceable if > provisioning via a suitable large LDIF file (grouper.ldif). Sorry, I'm not going to install grouper to test this bug. Please provide scripts to generate data that will reproduce the bug, and please do not use any 3rd party schemas in the data, that just makes it harder to setup a test environment. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6968) Glue objectclass created during Grouper provisioning
by Mark.Cairney＠ed.ac.uk 10 Jun '11

10 Jun '11

Full_Name: Mark Cairney Version: 2.4.25 OS: RHEL 5.5 x64 URL: ftp://ftp.ed.ac.uk/incoming/Mark-Cairney-110610.zip Submission from: (NULL) (129.215.200.77) During provisioning using Grouper (http://www.internet2.edu/grouper) to populate a tree of ou and posixGroup objects it looks like the request to create a child OU is being issued and granted. This results in the creation of a "ghost" parent OU with the glue objectClass as documented but syncrepl then constantly tries and fails to provision the ghost OU to the other servers (as shown in alderlog.txt). My cn=config is listed in cnconfig.txt for reference The issue can be reproduced by running Grouper's LDAP provisioner with Grouper configured to produce a "bushy" structure and it may also be reproduceable if provisioning via a suitable large LDIF file (grouper.ldif).

1 0

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by hyc＠symas.com 10 Jun '11

10 Jun '11

Daniel Pluta wrote: > Howard Chu wrote: >> daniel at pluta.biz wrote: >>> Please also have a look into the might be related patch, submitted in >>> ITS#6912 which addresses normalization of auth(c|z)Id of the form >>> "u:xxx" in general. Thank you very much. >> >> I see no bug here. The backslash was properly escaped, using the normal >> escaping rules for LDAP DNs. >> > > Yeah, you are right, but ... ;-) > ... I'm perhaps too. So please let me try to explain: > > The backslash is syntactically correct escaped (under the assumtion that > the string is indeed a "LDAP DN"). > > In my opinion authz-regexp (a slapd-config-statement string) completely > or partly does not always represent a "LDAP DN". It's quite often more > or less a combination of > > LDAP URI + optional regex + its optional expansions > > which probably should not be treated in general (especially in regard to > normalization) like a LDAP DN. > > This has led me to the submitted patch in ITS#6912 where I assume that > in contrast to authDN-normalization, the normalization of authIDs > (u:xxxx) in general is probably quite problematic, too... > > I'm aware that LDAP DNs need to be normalized in general, but I do not > understand why authcIDs or authz-regexp-expansions should need to be > normalized in general, too. > The authz-regexp expansion does not "need" to be normalized. But it is fed a DN, and that DN is normalized before any further processing, so if you want to match it, you must use the proper normalized string in your regexp: use "\\5C" instead of "\\". Next time send your usage questions to the -technical mailing list. This ITS is closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 10 Jun '11

10 Jun '11

Howard Chu wrote: > daniel at pluta.biz wrote: >> Please also have a look into the might be related patch, submitted in >> ITS#6912 which addresses normalization of auth(c|z)Id of the form >> "u:xxx" in general. Thank you very much. > > I see no bug here. The backslash was properly escaped, using the normal > escaping rules for LDAP DNs. > Yeah, you are right, but ... ;-) ... I'm perhaps too. So please let me try to explain: The backslash is syntactically correct escaped (under the assumtion that the string is indeed a "LDAP DN"). In my opinion authz-regexp (a slapd-config-statement string) completely or partly does not always represent a "LDAP DN". It's quite often more or less a combination of LDAP URI + optional regex + its optional expansions which probably should not be treated in general (especially in regard to normalization) like a LDAP DN. This has led me to the submitted patch in ITS#6912 where I assume that in contrast to authDN-normalization, the normalization of authIDs (u:xxxx) in general is probably quite problematic, too... I'm aware that LDAP DNs need to be normalized in general, but I do not understand why authcIDs or authz-regexp-expansions should need to be normalized in general, too.

1 0

Re: (ITS#6892) Segfault in Syncprov overlay
by hyc＠symas.com 10 Jun '11

10 Jun '11

ghola(a)rebelbase.com wrote: > Full_Name: Duncan Idaho > Version: 2.4.25 > OS: RHEL 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (204.10.36.147) > > > In my configuration slapd segfaults within a few hours repeatably when a NULL > value is somehow passed as a filter to test_filter in the syncprov overlay. > > I'm running "threads 64" as I have 62 consumers connecting and this was required > to prevent unrelated searches from timing out when all the consumers connect at > once. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x59832940 (LWP 2042)] > test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69 > 69 if ( f->f_choice& SLAPD_FILTER_UNDEFINED ) { > (gdb) bt > #0 test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69 > #1 0x00000000004db315 in syncprov_matchops (op=0x59831130, opc=0xbc91750, > saveit=1) at syncprov.c:1314 > #2 0x00000000004db6b5 in syncprov_op_mod (op=0x59831130, rs=<value optimized > out>) at syncprov.c:2124 > #3 0x000000000047e62a in overlay_op_walk (op=0x59831130, rs=0x59830f40, > which=op_modify, oi=0x8d7b50, on=0x8dc540) at backover.c:659 > #4 0x000000000047ec07 in over_op_func (op=0x59831130, rs=0x59830f40, > which=op_modify) at backover.c:721 > #5 0x000000000047404d in syncrepl_updateCookie (si=0x8d74e0, op=0x59831130, > syncCookie=0x59831aa0) at syncrepl.c:3292 > #6 0x0000000000479d0d in do_syncrep2 (ctx=<value optimized out>, arg=<value > optimized out>) at syncrepl.c:959 > #7 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at > syncrepl.c:1455 > #8 0x000000000041f7aa in connection_read_thread (ctx=0x59831d70, argv=<value > optimized out>) at connection.c:1251 > #9 0x00000000004ec5ec in ldap_int_thread_pool_wrapper (xpool=0x84de50) at > tpool.c:685 > #10 0x000000301b20673d in start_thread (arg=<value optimized out>) at > pthread_create.c:301 > #11 0x000000301aad44bd in clone () from /lib64/libc.so.6 > > Let me know if I can provide more info. A patch to avoid this particular crash is now in git master. However, it's still not clear to me why it occurred. Can you get this info from gdb: frame 1 print *ss -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6967) bug when migrating to cn=config with mixed-case schema names
by hyc＠symas.com 10 Jun '11

10 Jun '11

seth(a)energysec.org wrote: > Full_Name: Seth B. > Version: 2.4.25 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.37.253.46) > > > I moved from slapd.conf to cn=config using options -F and -f (forgot the exact > command but I think it was slapadd). I had a schema called EnergySec.ldif that > was migrated. It showed up as > /usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}EnergySec.ldif > following the conversion. > > However, when I tried modifying the schema using ADS and then ldapmodify, I > would get a error 32: No such object. With slapd in foreground mode, I found > that it was trying to access the lower-case version of the file: > > ldif_read_file: no entry file > "/usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}energysec.ldif" > > Since UNIX is case-sensitive, this obviously failed (the import kept the case as > EnergySec.ldif). > > I fixed it by manually renaming the ldif file to lower case and changing the dn > and cn inside the file. That was pretty hairy and I hope I didn't break anything > else but it semes to work. Thanks for the report, this is now fixed in git master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6967) bug when migrating to cn=config with mixed-case schema names
by seth＠energysec.org 09 Jun '11

09 Jun '11

Full_Name: Seth B. Version: 2.4.25 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.37.253.46) I moved from slapd.conf to cn=config using options -F and -f (forgot the exact command but I think it was slapadd). I had a schema called EnergySec.ldif that was migrated. It showed up as /usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}EnergySec.ldif following the conversion. However, when I tried modifying the schema using ADS and then ldapmodify, I would get a error 32: No such object. With slapd in foreground mode, I found that it was trying to access the lower-case version of the file: ldif_read_file: no entry file "/usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}energysec.ldif" Since UNIX is case-sensitive, this obviously failed (the import kept the case as EnergySec.ldif). I fixed it by manually renaming the ldif file to lower case and changing the dn and cn inside the file. That was pretty hairy and I hope I didn't break anything else but it semes to work.

1 0

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by hyc＠symas.com 09 Jun '11

09 Jun '11

daniel(a)pluta.biz wrote: > Please also have a look into the might be related patch, submitted in > ITS#6912 which addresses normalization of auth(c|z)Id of the form > "u:xxx" in general. Thank you very much. I see no bug here. The backslash was properly escaped, using the normal escaping rules for LDAP DNs. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 09 Jun '11

09 Jun '11

Please also have a look into the might be related patch, submitted in ITS#6912 which addresses normalization of auth(c|z)Id of the form "u:xxx" in general. Thank you very much.

1 0

Re: (ITS#6966) admin guide references "Start TLS" instead of StartTLS
by quanah＠zimbra.com 09 Jun '11

09 Jun '11

--On Thursday, June 09, 2011 10:19 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: NA > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > The admin guide refers to "Start TLS" in multiple locations instead of > "StartTLS", which leads to confusion among end users, and makes searching > for the startTLS pieces a pain. I will fix shortly. > I will mark this as invalid, as this is how it is described in all the RFCs as well (Start TLS). --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by hyc＠symas.com 09 Jun '11

09 Jun '11

mark.cave-ayland(a)siriusit.co.uk wrote: > Full_Name: Mark Cave-Ayland > Version: 2.4.23 > OS: Linux/Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.187.123.11) > > > Hi all, > > We have an issue on one of our production systems whereby openldap is not > enforcing the ACLs on a back-perl subordinate database. Keep in mind, this is back-perl's documented behavior. >>> ACCESS CONTROL The perl backend does not honor any of the access control semantics described in slapd.access(5); all access control is delegated to the underlying PERL scripting. Only read (=r) access to the entry pseudo- attribute and to the other attribute values of the entries returned by the search operation is honored, which is performed by the frontend. <<< Treating this as an enhancement request. > In this particular system, the membership of certain groups stored within LDAP > is determined by some customised logic in a Perl module which dynamically > generates LDAP objects with posixGroup/groupOfNames entries conditionally based > upon the values of existing LDAP attributes within the tree. However, since > these internal LDAP attribute lookups can be quite slow, we wish to hide them > from all but a small minority of bind DNs. Unfortunately what we are finding is > that the back-perl module is not respecting the ACLs in slapd.conf. > > The following files can be used to reproduce this issue with openldap 2.4.23: > > http://pastebin.siriusit.co.uk/perlacl/slapd.conf > http://pastebin.siriusit.co.uk/perlacl/perlacl.ldif > http://pastebin.siriusit.co.uk/perlacl/PerlACL.pm > > The password for both the "cn=admin,dc=my-domain,dc=com" and the > "cn=restricted,dc=my-domain,dc=com" DNs is secret. > > The ACLs in the above slapd.conf look like this: > > access to dn.subtree="ou=perl,dc=my-domain,dc=com" > by dn="cn=admin,dc=my-domain,dc=com" read > by dn="cn=restricted,dc=my-domain,dc=com" none > > access to dn.subtree="ou=hidden,dc=my-domain,dc=com" > by dn="cn=admin,dc=my-domain,dc=com" read > by dn="cn=restricted,dc=my-domain,dc=com" none > > access to * > by dn="cn=admin,dc=my-domain,dc=com" write > by dn="cn=restricted,dc=my-domain,dc=com" read > by * auth > > Using these ACLs, I would expect that cn=admin should be able to read the whole > directory, whereas cn=restricted should not be able to see either the > "ou=hidden,dc=my-domain,dc=com" DN subtree nor the "ou=perl,dc=my-domain,dc=com" > DN subtree. > > However, performing an LDAP search binding as cn=restricted gives the following > output: > > build@zeno:~$ ldapsearch -LLL -H ldap://localhost:10389 -D > 'cn=restricted,dc=my-domain,dc=com' -b 'dc=my-domain,dc=com' -xW > Enter LDAP Password: > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: real > > dn: ou=realtest1,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest1 > > dn: ou=realtest2,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest2 > > dn: ou=realtest3,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest3 > > dn: ou=realtest4,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest4 > > dn: ou=realtest5,ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: realtest5 > > dn: cn=restricted,dc=my-domain,dc=com > objectClass: simpleSecurityObject > objectClass: organizationalRole > cn: restricted > description: restricted user > userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 > > dn: cn=admin,dc=my-domain,dc=com > objectClass: simpleSecurityObject > objectClass: organizationalRole > cn:: YWRtaW4g > description: admin user > userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 > > dn: ou=perltest5,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest5 > > dn: ou=perltest4,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest4 > > dn: ou=perltest3,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest3 > > dn: ou=perltest2,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest2 > > dn: ou=perltest1,ou=perl,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > ou: perltest1 > > > In other words, the "ou=hidden,dc=my-domain,dc=com" subtree is correctly hidden > from the cn=restricted user, whereas the "ou=perl,dc=my-domain,dc=com" subtree > is not. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6966) admin guide references "Start TLS" instead of StartTLS
by quanah＠OpenLDAP.org 09 Jun '11

09 Jun '11

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) The admin guide refers to "Start TLS" in multiple locations instead of "StartTLS", which leads to confusion among end users, and makes searching for the startTLS pieces a pain. I will fix shortly.

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by hyc＠symas.com 09 Jun '11

09 Jun '11

mark.cave-ayland(a)siriusit.co.uk wrote: > On 09/06/11 00:21, Quanah Gibson-Mount wrote: > >>> An update on this bug report: with a modified slapd.conf and a small >>> patch to the back-perl module, I can use the ACL mask to ensure that the >>> perl search function doesn't get invoked if disallowed by the ACLs. >>> >>> The patch works by creating a "fake" empty entry whose DN is the base of >>> the search, and then passing this entry into access_allowed() using code >>> borrowed from one of the other backends to either deny or allow access. >>> >>> http://pastebin.siriusit.co.uk/perlacl/slapd2.conf >>> http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch >> >> These are not accessible. > > Hi Quanah, > > Ah yes indeed - that server was decommissioned last month. I've since > reinstated the files from a backup onto a new server and updated DNS to > point to it. Can you verify that you can now download them? Thanks, got it now. The patch leaks memory. I'll commit a fixed version of it shortly. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by mark.cave-ayland＠siriusit.co.uk 09 Jun '11

09 Jun '11

On 09/06/11 00:21, Quanah Gibson-Mount wrote: >> An update on this bug report: with a modified slapd.conf and a small >> patch to the back-perl module, I can use the ACL mask to ensure that the >> perl search function doesn't get invoked if disallowed by the ACLs. >> >> The patch works by creating a "fake" empty entry whose DN is the base of >> the search, and then passing this entry into access_allowed() using code >> borrowed from one of the other backends to either deny or allow access. >> >> http://pastebin.siriusit.co.uk/perlacl/slapd2.conf >> http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch > > These are not accessible. Hi Quanah, Ah yes indeed - that server was decommissioned last month. I've since reinstated the files from a backup onto a new server and updated DNS to point to it. Can you verify that you can now download them? Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

(ITS#6965) Ldap ld210_en for Mdaemon ver 11.0.1-urgent
by elena.morozova＠softline.ru 09 Jun '11

09 Jun '11

Full_Name: Elena Morozova Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.141.102.2) Hello, Earlier our client used Ldap ld210_en for Mdaemon ver 11.0.1. What can you advise to use instead of Ldap ld210_en for Mdaemon ver 11.0.1? Thank you.

1 0

Re: (ITS#6830) slapo-ppolicy.5 has incorrect schema fragments
by hyc＠symas.com 09 Jun '11

09 Jun '11

Andrew Findlay wrote: > On Tue, Feb 15, 2011 at 05:02:52AM -0800, Howard Chu wrote: > >>> slapo-ppolicy.5 incorrectly includes the NO-USER-MODIFICATION flag in the schema >>> fragments for pwdPolicySubentry and pwdAccountLockedTime. >> >> That's how they were defined in the IETF Draft. The schema fragments >> in the manpage were copied directly from the spec. The fact that the >> current implementation deviates from the spec is just out of >> necessity to make things work at all in our present code base. > > Certainly the use of pwdPolicySubentry differs from the > intention of the draft (which I believe was intending to use > real X.500-style subentries). > > The case of pwdAccountLockedTime is arguable. > draft-behera-ldap-password-policy-xx.txt says: > > This attribute holds the time that the user's account was locked. A > locked account means that the password may no longer be used to > authenticate. A 000001010000Z value means that the account has been > locked permanently, and that only a password administrator can unlock > the account. > > Unfortunately it says nothing about *how* a password > administrator should do that when the attribute is marked > NO-USER-MODIFICATION. I would argue that this is a > deficiency in the draft, and that the current OpenLDAP > behaviour is more useful. > >> Things will not always work this way... > > Indeed, but I would prefer the manpages to reflect the > reality of the current release! I note that in ppolicy.c we have: { "( 1.3.6.1.4.1.42.2.27.8.1.17 " "NAME ( 'pwdAccountLockedTime' ) " "DESC 'The time an user account was locked' " "EQUALITY generalizedTimeMatch " "ORDERING generalizedTimeOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " "SINGLE-VALUE " #if 0 /* Not until Relax control is released */ "NO-USER-MODIFICATION " #endif "USAGE directoryOperation )", We have in fact released support for the Relax control, so it's probably time to unifdef these bits and go back to the documented behavior. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: [PATCH] More for ITS#6872
by hyc＠symas.com 09 Jun '11

09 Jun '11

cmikk(a)qwest.net wrote: > [Note: The previous patch did not fix the problem when > the consumer's access was restricted to the replicated > subtree. This patch fixes that.] Both applied to git master, thanks. > > Perform the internal FIND_CSN search based at the backend's suffix with the > privileges of the backend's root DN. > --- > servers/slapd/overlays/syncprov.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c > index 0c148f9..a058e19 100644 > --- a/servers/slapd/overlays/syncprov.c > +++ b/servers/slapd/overlays/syncprov.c > @@ -661,6 +661,8 @@ again: > if ( BER_BVISEMPTY(&cf.f_av_value )) { > cf.f_av_value = *csn; > } > + fop.o_dn = op->o_bd->be_rootdn; > + fop.o_ndn = op->o_bd->be_rootndn; > fop.o_req_dn = op->o_bd->be_suffix[0]; > fop.o_req_ndn = op->o_bd->be_nsuffix[0]; > /* Look for exact match the first time */ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6671) multi-master replication fails to delete objects from consumer
by hyc＠symas.com 08 Jun '11

08 Jun '11

hyc(a)symas.com wrote: > bcolston(a)xtec.com wrote: >> Full_Name: Barry Colston >> Version: 2.4.23 >> OS: Fedora 10 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.255.208.200) > > I'm looking at your test case now. One thing to note, serverIDs must all be > non-zero in a multi-master configuration. serverID == 0 is only valid in > single-master replication. > >> When a "Refresh Present" phase is performed at a multi-master consumer, objects >> that were deleted at the provider >> while the consumer was down are not deleted from the multi-master consumer (if >> the provider is brought down and back up after the consumer is down). This >> problem can be duplicated as follows: >> 1. Start provider >> 2. Start consumer, which is configured as a multi-master server >> 3. Add 10 records to the provider and wait until the records are replicated to >> the multi-master consumer >> 4. Stop the consumer >> 5. Delete 3 of the records that were added to the provider >> 6. Stop the provider >> 7. Start the provider >> 8. Start the consumer >> 9. After giving the consumer time to perform the refresh present phase, the 3 >> records that were deleted at the provider while the consumer was down >> are still present on the consumer and were not deleted during the refresh >> present phase >> >> Note: the consumer database must have a contextCSN attribute value present for >> itself (e.g., there should be 2 contextCSN attribute values >> present in the consumer database, one for the provider (in my configuration, >> this is serverID 000), and one value for the consumer >> (in my configuration, this is serverID 001). An example of the contextCSN >> values follows: I see. This configuration is not supported. "Multi-Master" requires the servers to be full peers. In your configuration, you have a dedicated provider, it never pulls changes from the consumer, while your consumer is pulling from the provider and accepting local changes. Since the consumer has changes that the provider doesn't know about, the sync protocol is broken. The consumer cannot conclusively state that all entries the provider doesn't know about must be deleted, since some of those entries may have legitimately been created on the consumer, so it cannot execute the delete-nonpresent step. Closing this ITS. >> dn: dc=authentx >> objectClass: top >> entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f >> contextCSN: 20101012154030.379053Z#000000#000#000000 >> contextCSN: 20101012141508.956053Z#000000#001#000000 >> >> OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches). >> >> Consumer log file from -d sync logging option: >> @(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $ >> Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd >> slapd starting >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET >> do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT >> do_syncrep2: rid=001 >> cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000 >> slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000 >> slap_graduate_commit_csn: removing 0x1841b18 >> 20101012180219.072053Z#000000#000#000000 >> daemon: shutdown requested and initiated. >> slapd shutdown: waiting for 1 operations/tasks to finish >> slapd stopped. >> >> Provider slapd.conf file: >> # >> include /usr/local/etc/openldap/schema/core.schema >> include /usr/local/etc/openldap/schema/cosine.schema >> include /usr/local/etc/openldap/schema/inetorgperson.schema >> include /usr/local/etc/openldap/schema/nis.schema >> >> include /usr/local/etc/openldap/schema/authentx.schema >> >> pidfile /usr/local/var/slapd.sync1.pid >> argsfile /usr/local/var/slapd.sync1.args >> >> allow bind_v2 >> >> threads 32 >> >> #loglevel 416 >> password-hash {SSHA} >> >> serverID 000 >> >> database bdb >> suffix "dc=authentx" >> rootdn "cn=xroot,dc=authentx" >> rootpw SECRET >> directory /authentx/db/ldap/authentx-sync1 >> >> overlay syncprov >> syncprov-checkpoint 100 15 >> syncprov-sessionlog 150000 >> >> # checkpoint<kbytes> <min> >> checkpoint 128 20 >> >> #index for the objectclass >> index objectClass eq,pres >> index cid,eid,pid eq,pres >> index gcoid eq,pres >> index sysid,certid eq,pres >> index imageid,bioid eq,pres >> index addrid,emplid eq,pres >> index acid,apid,aeid eq,pres >> index acpid,agpid eq,pres >> index deviceid eq,pres >> index qid eq,pres >> index scid eq,pres >> index docid eq,pres >> index procid eq,pres >> index prochandlerid eq,pres >> index ounit eq,pres >> index credentials eq,pres >> index entities eq,pres >> index permissions eq,pres >> index region eq,pres >> index aliasedObjectName eq,pres >> index proctype eq,pres >> index procname eq,pres >> index status eq,pres >> index upi,ediident eq,pres >> index xsync eq,pres >> index role,xrole eq,pres >> index eroid eq,pres >> index esfunction eq,pres >> index nippsector eq,pres >> index ercog,ercoop eq,pres >> index eropron eq,pres >> index xsyncid eq,pres >> index stockid eq,pres >> index stocktypecode eq,pres >> index lotserialin eq,pres >> index lotserialout eq,pres >> index entryCSN,entryUUID eq >> index incl eq,pres >> >> cachesize 10000 >> dncachesize 20000 >> idlcachesize 1000 >> >> sizelimit 500000 >> timelimit 36000 >> include /usr/local/etc/openldap/acl.authentx >> >> database monitor >> >> Consumer slapd.conf file: >> # >> include /usr/local/etc/openldap/schema/core.schema >> include /usr/local/etc/openldap/schema/cosine.schema >> include /usr/local/etc/openldap/schema/inetorgperson.schema >> include /usr/local/etc/openldap/schema/nis.schema >> >> include /usr/local/etc/openldap/schema/authentx.schema >> >> pidfile /usr/local/var/slapd.sync2.pid >> argsfile /usr/local/var/slapd.sync2.args >> >> allow bind_v2 >> >> threads 32 >> >> #loglevel 416 >> password-hash {SSHA} >> >> serverID 001 >> >> database bdb >> suffix "dc=authentx" >> rootdn "cn=xroot,dc=authentx" >> rootpw SECRET >> directory /authentx/db/ldap/authentx-sync2 >> >> overlay syncprov >> syncprov-checkpoint 100 15 >> syncprov-sessionlog 5000 >> >> # SLAVE server replication section >> syncrepl rid=001 >> provider=ldap://localhost:3891 >> type=refreshAndPersist >> retry="30 60 60 +" >> searchbase="dc=authentx" >> scope=sub >> schemachecking=off >> bindmethod=simple >> binddn="cn=xroot,dc=authentx" >> credentials="SECRET" >> >> mirrormode on >> >> # checkpoint<kbytes> <min> >> checkpoint 128 20 >> >> #index for the objectclass >> index objectClass eq,pres >> index cid,eid,pid eq,pres >> index gcoid eq,pres >> index sysid,certid eq,pres >> index imageid,bioid eq,pres >> index addrid,emplid eq,pres >> index acid,apid,aeid eq,pres >> index acpid,agpid eq,pres >> index deviceid eq,pres >> index qid eq,pres >> index scid eq,pres >> index docid eq,pres >> index procid eq,pres >> index prochandlerid eq,pres >> index ounit eq,pres >> index credentials eq,pres >> index entities eq,pres >> index permissions eq,pres >> index region eq,pres >> index aliasedObjectName eq,pres >> index proctype eq,pres >> index procname eq,pres >> index status eq,pres >> index upi,ediident eq,pres >> index xsync eq,pres >> index role,xrole eq,pres >> index eroid eq,pres >> index esfunction eq,pres >> index nippsector eq,pres >> index ercog,ercoop eq,pres >> index eropron eq,pres >> index xsyncid eq,pres >> index stockid eq,pres >> index stocktypecode eq,pres >> index lotserialin eq,pres >> index lotserialout eq,pres >> index entryCSN,entryUUID eq >> index incl eq,pres >> >> cachesize 10000 >> dncachesize 20000 >> idlcachesize 1000 >> >> sizelimit 100000 >> timelimit 36000 >> # the authentx database access control directives >> include /usr/local/etc/openldap/acl.authentx >> >> database monitor >> >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6880) SECURITY: ldap_free_urllist segfault
by Howard Chu 08 Jun '11

08 Jun '11

> Full_Name: Marcus Rottensteiner > Version: 2.4.24 > OS: gentoo > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (188.20.205.34) > > > running a php program, openldap 2.4.24 has a problem in libldap_r-2.4.so.2 > > in conjunction with php 5.3 (tested 5.3.5 , 5.3.6) ? > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff39bcb4b in ldap_free_urllist () from /usr//lib/libldap-2.4.so.2 > (gdb) backtrace > #0 0x00007ffff39bcb4b in ldap_free_urllist () from /usr//lib/libldap-2.4.so.2 > #1 0x00007ffff1a60c1b in ?? () from /usr/lib64/libldap_r-2.4.so.2 > #2 0x00007ffff1a4680e in ?? () from /usr/lib64/libldap_r-2.4.so.2 > #3 0x0000000000000030 in ?? () > #4 0x0000000000000000 in ?? () > > Reverting to openldap 2.4.23 does not cause a problem ! Your trace shows that both libldap and libldap_r are present. Your PHP is built incorrectly. You cannot link both libraries into the same program; they are not compatible. Closing this ITS.

1 0

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com 08 Jun '11

08 Jun '11

hyc(a)symas.com wrote: > ipuleston(a)SonicWALL.com wrote: >> The patch that I submitted above has a memory leak due not freeing "ber" > when returning error LDAP_X_CONNECTING from function > ldap_send_initial_request(). I have uploaded a new version of the patch with > this fixed to ftp.openldap.org/incoming as ian-puleston-110412.patch.2 (note > the .2 on the end - it was a 2nd attempt after I forgot to specify ASCII mode). > > Unfortunately the patch was made against 2.4.23 and not against HEAD. It does > not apply cleanly to current git. Patches must always be submitted against the > development code, not against released code. I've committed an alternate patch to git master. > > I'm pretty sure that this chunk can never do anything useful. > > diff -u libldap.orig/request.c libldap/request.c > --- libldap.orig/request.c 2010-06-10 10:39:48.000000000 -0700 > +++ libldap/request.c 2011-04-12 12:11:20.769166100 -0700 > @@ -446,7 +462,21 @@ > lc->lconn_server = ldap_url_dup( srv ); > } > > - lc->lconn_status = async ? LDAP_CONNST_CONNECTING : LDAP_CONNST_CONNECTED; > + if ( async ) { > +#ifdef HAVE_TLS > + void *ssl = NULL; > + ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_GET_SSL, (void *)&ssl ); > + if ( ssl ) { > + /* the connect finished and tls was started */ > + lc->lconn_status = LDAP_CONNST_CONNECTED; > + } else > +#endif > + { > + lc->lconn_status = LDAP_CONNST_CONNECTING; > + } > + } else { > + lc->lconn_status = LDAP_CONNST_CONNECTED; > + } > #ifdef LDAP_R_COMPILE > ldap_pvt_thread_mutex_lock(&ld->ld_conn_mutex ); > #endif > > The connection has just been created, asynchronously, so there's no way that > the TLS layer was already started when it got here. Also, even if this was > valid, it obviously would only apply for OPT_X_TLS_HARD || ldaps, but you > haven't checked that condition here. Ultimately it appears that this test is a > no-op. > > Also, I suggest that you only check for CONNST_CONNECTING in the callers, and > do the TLS check in the check function, like this: > > +int > +ldap_int_check_async_open( LDAP *ld, LDAPConn *lc, LDAPURLDesc *srv, > ber_socket_t sd ) > +{ > + struct timeval tv = { 0 }; > + int rc; > + > + rc = ldap_int_poll( ld, sd,&tv ); > + switch ( rc ) { > + case 0: > + /* now ready to start tls */ > + lc->lconn_status = LDAP_CONNST_CONNECTED; > + break; > + > + default: > + rc = -1; > + return rc; > + case -2: > + /* connect not completed yet */ > + ld->ld_errno = LDAP_X_CONNECTING; > + return rc; > + } > + > +#ifdef HAVE_TLS > + if ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || > + !strcmp( srv->lud_scheme, "ldaps" )) { > + > + ++lc->lconn_refcnt; /* avoid premature free */ > + > + rc = ldap_int_tls_start( ld, lc, srv ); > + > + --lc->lconn_refcnt; > + } > +#endif > + return rc; > +} > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6671) multi-master replication fails to delete objects from consumer
by hyc＠symas.com 08 Jun '11

08 Jun '11

bcolston(a)xtec.com wrote: > Full_Name: Barry Colston > Version: 2.4.23 > OS: Fedora 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.255.208.200) I'm looking at your test case now. One thing to note, serverIDs must all be non-zero in a multi-master configuration. serverID == 0 is only valid in single-master replication. > When a "Refresh Present" phase is performed at a multi-master consumer, objects > that were deleted at the provider > while the consumer was down are not deleted from the multi-master consumer (if > the provider is brought down and back up after the consumer is down). This > problem can be duplicated as follows: > 1. Start provider > 2. Start consumer, which is configured as a multi-master server > 3. Add 10 records to the provider and wait until the records are replicated to > the multi-master consumer > 4. Stop the consumer > 5. Delete 3 of the records that were added to the provider > 6. Stop the provider > 7. Start the provider > 8. Start the consumer > 9. After giving the consumer time to perform the refresh present phase, the 3 > records that were deleted at the provider while the consumer was down > are still present on the consumer and were not deleted during the refresh > present phase > > Note: the consumer database must have a contextCSN attribute value present for > itself (e.g., there should be 2 contextCSN attribute values > present in the consumer database, one for the provider (in my configuration, > this is serverID 000), and one value for the consumer > (in my configuration, this is serverID 001). An example of the contextCSN > values follows: > > dn: dc=authentx > objectClass: top > entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f > contextCSN: 20101012154030.379053Z#000000#000#000000 > contextCSN: 20101012141508.956053Z#000000#001#000000 > > OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches). > > Consumer log file from -d sync logging option: > @(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $ > Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd > slapd starting > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET > do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT > do_syncrep2: rid=001 > cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000 > slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000 > slap_graduate_commit_csn: removing 0x1841b18 > 20101012180219.072053Z#000000#000#000000 > daemon: shutdown requested and initiated. > slapd shutdown: waiting for 1 operations/tasks to finish > slapd stopped. > > Provider slapd.conf file: > # > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/nis.schema > > include /usr/local/etc/openldap/schema/authentx.schema > > pidfile /usr/local/var/slapd.sync1.pid > argsfile /usr/local/var/slapd.sync1.args > > allow bind_v2 > > threads 32 > > #loglevel 416 > password-hash {SSHA} > > serverID 000 > > database bdb > suffix "dc=authentx" > rootdn "cn=xroot,dc=authentx" > rootpw SECRET > directory /authentx/db/ldap/authentx-sync1 > > overlay syncprov > syncprov-checkpoint 100 15 > syncprov-sessionlog 150000 > > # checkpoint<kbytes> <min> > checkpoint 128 20 > > #index for the objectclass > index objectClass eq,pres > index cid,eid,pid eq,pres > index gcoid eq,pres > index sysid,certid eq,pres > index imageid,bioid eq,pres > index addrid,emplid eq,pres > index acid,apid,aeid eq,pres > index acpid,agpid eq,pres > index deviceid eq,pres > index qid eq,pres > index scid eq,pres > index docid eq,pres > index procid eq,pres > index prochandlerid eq,pres > index ounit eq,pres > index credentials eq,pres > index entities eq,pres > index permissions eq,pres > index region eq,pres > index aliasedObjectName eq,pres > index proctype eq,pres > index procname eq,pres > index status eq,pres > index upi,ediident eq,pres > index xsync eq,pres > index role,xrole eq,pres > index eroid eq,pres > index esfunction eq,pres > index nippsector eq,pres > index ercog,ercoop eq,pres > index eropron eq,pres > index xsyncid eq,pres > index stockid eq,pres > index stocktypecode eq,pres > index lotserialin eq,pres > index lotserialout eq,pres > index entryCSN,entryUUID eq > index incl eq,pres > > cachesize 10000 > dncachesize 20000 > idlcachesize 1000 > > sizelimit 500000 > timelimit 36000 > include /usr/local/etc/openldap/acl.authentx > > database monitor > > Consumer slapd.conf file: > # > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/nis.schema > > include /usr/local/etc/openldap/schema/authentx.schema > > pidfile /usr/local/var/slapd.sync2.pid > argsfile /usr/local/var/slapd.sync2.args > > allow bind_v2 > > threads 32 > > #loglevel 416 > password-hash {SSHA} > > serverID 001 > > database bdb > suffix "dc=authentx" > rootdn "cn=xroot,dc=authentx" > rootpw SECRET > directory /authentx/db/ldap/authentx-sync2 > > overlay syncprov > syncprov-checkpoint 100 15 > syncprov-sessionlog 5000 > > # SLAVE server replication section > syncrepl rid=001 > provider=ldap://localhost:3891 > type=refreshAndPersist > retry="30 60 60 +" > searchbase="dc=authentx" > scope=sub > schemachecking=off > bindmethod=simple > binddn="cn=xroot,dc=authentx" > credentials="SECRET" > > mirrormode on > > # checkpoint<kbytes> <min> > checkpoint 128 20 > > #index for the objectclass > index objectClass eq,pres > index cid,eid,pid eq,pres > index gcoid eq,pres > index sysid,certid eq,pres > index imageid,bioid eq,pres > index addrid,emplid eq,pres > index acid,apid,aeid eq,pres > index acpid,agpid eq,pres > index deviceid eq,pres > index qid eq,pres > index scid eq,pres > index docid eq,pres > index procid eq,pres > index prochandlerid eq,pres > index ounit eq,pres > index credentials eq,pres > index entities eq,pres > index permissions eq,pres > index region eq,pres > index aliasedObjectName eq,pres > index proctype eq,pres > index procname eq,pres > index status eq,pres > index upi,ediident eq,pres > index xsync eq,pres > index role,xrole eq,pres > index eroid eq,pres > index esfunction eq,pres > index nippsector eq,pres > index ercog,ercoop eq,pres > index eropron eq,pres > index xsyncid eq,pres > index stockid eq,pres > index stocktypecode eq,pres > index lotserialin eq,pres > index lotserialout eq,pres > index entryCSN,entryUUID eq > index incl eq,pres > > cachesize 10000 > dncachesize 20000 > idlcachesize 1000 > > sizelimit 100000 > timelimit 36000 > # the authentx database access control directives > include /usr/local/etc/openldap/acl.authentx > > database monitor > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6828) TLS fails to start when LDAP_OPT_CONNECT_ASYNC is used
by hyc＠symas.com 08 Jun '11

08 Jun '11

ipuleston(a)SonicWALL.com wrote: > The patch that I submitted above has a memory leak due not freeing "ber" when returning error LDAP_X_CONNECTING from function ldap_send_initial_request(). I have uploaded a new version of the patch with this fixed to ftp.openldap.org/incoming as ian-puleston-110412.patch.2 (note the .2 on the end - it was a 2nd attempt after I forgot to specify ASCII mode). Unfortunately the patch was made against 2.4.23 and not against HEAD. It does not apply cleanly to current git. Patches must always be submitted against the development code, not against released code. I'm pretty sure that this chunk can never do anything useful. diff -u libldap.orig/request.c libldap/request.c --- libldap.orig/request.c 2010-06-10 10:39:48.000000000 -0700 +++ libldap/request.c 2011-04-12 12:11:20.769166100 -0700 @@ -446,7 +462,21 @@ lc->lconn_server = ldap_url_dup( srv ); } - lc->lconn_status = async ? LDAP_CONNST_CONNECTING : LDAP_CONNST_CONNECTED; + if ( async ) { +#ifdef HAVE_TLS + void *ssl = NULL; + ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_GET_SSL, (void *)&ssl ); + if ( ssl ) { + /* the connect finished and tls was started */ + lc->lconn_status = LDAP_CONNST_CONNECTED; + } else +#endif + { + lc->lconn_status = LDAP_CONNST_CONNECTING; + } + } else { + lc->lconn_status = LDAP_CONNST_CONNECTED; + } #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_lock( &ld->ld_conn_mutex ); #endif The connection has just been created, asynchronously, so there's no way that the TLS layer was already started when it got here. Also, even if this was valid, it obviously would only apply for OPT_X_TLS_HARD || ldaps, but you haven't checked that condition here. Ultimately it appears that this test is a no-op. Also, I suggest that you only check for CONNST_CONNECTING in the callers, and do the TLS check in the check function, like this: +int +ldap_int_check_async_open( LDAP *ld, LDAPConn *lc, LDAPURLDesc *srv, ber_socket_t sd ) +{ + struct timeval tv = { 0 }; + int rc; + + rc = ldap_int_poll( ld, sd, &tv ); + switch ( rc ) { + case 0: + /* now ready to start tls */ + lc->lconn_status = LDAP_CONNST_CONNECTED; + break; + + default: + rc = -1; + return rc; + case -2: + /* connect not completed yet */ + ld->ld_errno = LDAP_X_CONNECTING; + return rc; + } + +#ifdef HAVE_TLS + if ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || + !strcmp( srv->lud_scheme, "ldaps" )) { + + ++lc->lconn_refcnt; /* avoid premature free */ + + rc = ldap_int_tls_start( ld, lc, srv ); + + --lc->lconn_refcnt; + } +#endif + return rc; +} -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

RE: (ITS#6964) ./configure bug when specifying openssl as the TLS library to use
by the_uhu＠hotmail.com 08 Jun '11

08 Jun '11

--_845f4083-7211-40a8-bc3d-f1e94a6babb0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've just downloaded openldap stable fresh=2C opened up configure and this = is at line 19408 without an if check: LIBS=3D"-lssl -lcrypto -lRSAglue -lrsaref $LIBS" Also checked the source repository on the website and it's there also. Can you please double check? Paul. > Date: Wed=2C 8 Jun 2011 22:13:55 +0000 > From: openldap-its(a)OpenLDAP.org > To: the_uhu(a)hotmail.com > Subject: Re: (ITS#6964) ./configure bug when specifying openssl as the TL= S library to use >=20 > I don't know where your configure script came from=2C but there's nothing= related > to OpenSSL at line 19408 of the current released configure script=2C and = our > script has had logic to detect -lrsaref since 1999. >=20 > Closing this ITS. Use the actual configure script supplied by the OpenLDA= P > Project. = --_845f4083-7211-40a8-bc3d-f1e94a6babb0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style> </head> <body class=3D'hmmessage'> I've just downloaded openldap stable fresh=2C opened up configure and this = is at line 19408 without an if check: LIBS=3D"-lssl -lcrypto -lRSAgl= ue -lrsaref $LIBS" Also checked the source repository on the website= and it's there also. Can you please double check? Paul. <= br> &gt=3B Date: Wed=2C 8 Jun 2011 22:13:55 +0000 &gt=3B From: openld= ap-its(a)OpenLDAP.org &gt=3B To: the_uhu(a)hotmail.com &gt=3B Subject: Re= : (ITS#6964) ./configure bug when specifying openssl as the TLS library to = use &gt=3B &gt=3B I don't know where your configure script came from= =2C but there's nothing related &gt=3B to OpenSSL at line 19408 of the c= urrent released configure script=2C and our &gt=3B script has had logic = to detect -lrsaref since 1999. &gt=3B &gt=3B Closing this ITS. Use t= he actual configure script supplied by the OpenLDAP &gt=3B Project. = </body> </html>= --_845f4083-7211-40a8-bc3d-f1e94a6babb0_--

1 0

Re: (ITS#6688) OpenLDAP 2.4.23 doesn't enforce ACLs on back-perl subordinate database
by quanah＠zimbra.com 08 Jun '11

08 Jun '11

--On Friday, October 29, 2010 4:35 PM +0000 mark.cave-ayland(a)siriusit.co.uk wrote: > Hi all, > > An update on this bug report: with a modified slapd.conf and a small > patch to the back-perl module, I can use the ACL mask to ensure that the > perl search function doesn't get invoked if disallowed by the ACLs. > > The patch works by creating a "fake" empty entry whose DN is the base of > the search, and then passing this entry into access_allowed() using code > borrowed from one of the other backends to either deny or allow access. > > http://pastebin.siriusit.co.uk/perlacl/slapd2.conf > http://pastebin.siriusit.co.uk/perlacl/openldap-backperl-acls.patch These are not accessible. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 08 Jun '11

08 Jun '11

----- "Howard Chu" <hyc(a)symas.com> wrote: > Howard Chu wrote: > > Tyler Gates wrote: > >> After applying the patches for ITS #6848 and ITS #6898 I still get > crashes. > >> Here's the latest: > > ??? neither #6848 nor #6898 are relevant to pcache. I figured probably not but thought it may be important to know in terms as this is not just a straight 2.4.25 build... > > I think you should try the RE24 branch at this point, as a number of > other > pcache-related fixes have been merged there. Are you referring to OPENLDAP_REL_ENG_2_4 in the git tree? I'm not sure if I'll have the time (work) to tackle that but I'll see what I can do. > > > > Looks like a double-free. Can you reproduce this consistently? If > so, what are > > the steps? can you run slapd under valgrind and reproduce this? I can reproduce it consistently in terms that it crashes reliably after 2 to 4 days with 1 to 2 Linux hosts connected via pam-ldap account sessions. Other than that I've not been able to find a way to make it crash on demand. I do know it won't crash if it is run in the foreground with -d -1. I'm running it now under valgrind, any options you are looking for in particular? I'll report back the next time it crashes and/or I can try RE24. > >> > >> Program received signal SIGABRT, Aborted. > >> [Switching to Thread 0xae1edb70 (LWP 6121)] > >> 0xb76e2430 in __kernel_vsyscall () > >> (gdb) > >> (gdb) > >> (gdb) bt > >> #0 0xb76e2430 in __kernel_vsyscall () > >> #1 0xb71b4651 in *__GI_raise (sig=6) at > >> ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > >> #2 0xb71b7a82 in *__GI_abort () at abort.c:92 > >> #3 0xb71eb49d in __libc_message (do_abort=2, fmt=0xb72bff98 "*** > glibc > >> detected *** %s: %s: 0x%s ***\n") at > >> ../sysdeps/unix/sysv/linux/libc_fatal.c:189 > >> #4 0xb71f5591 in malloc_printerr (action=<value optimized out>, > str=0x6 > >> <Address 0x6 out of bounds>, ptr=0xb9584e80) at malloc.c:6266 > >> #5 0xb71f6de8 in _int_free (av=<value optimized out>, p=<value > >> optimized out>) at malloc.c:4794 > >> #6 0xb71f9ecd in *__GI___libc_free (mem=0xb9584e80) at > malloc.c:3738 > >> #7 0xb768ac20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2 > >> #8 0xb768acaf in ber_bvarray_free_x () from > /usr/lib/liblber-2.4.so.2 > >> #9 0xb768acf5 in ber_bvarray_free () from > /usr/lib/liblber-2.4.so.2 > >> #10 0xb7743e5d in attr_clean (a=0xb6dcc06c) at > >> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:148 > >> #11 0xb7743efb in attrs_free (a=0xb6dcc06c) at > >> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:198 > >> #12 0xb6d84b7f in hdb_cache_modify (bdb=0xb9536e10, e=0xb94f1dac, > >> newAttrs=0xb6dd6884, txn=0xb2176970, lock=0xae1ec930) at > cache.c:1238 > >> #13 0xb6d7008c in hdb_modify (op=0xae1eccfc, rs=0xae1ecad0) at > modify.c:662 > >> #14 0xb6d52e81 in remove_query_data (op=<value optimized out>, > >> query_uuid=<value optimized out>) > >> at > /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:1829 > >> #15 0xb6d53d0b in consistency_check (ctx=0xae1ed1dc, > arg=0xb955e018) at > >> /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:3520 > >> #16 0xb769d8b4 in ?? () from /usr/lib/libldap_r-2.4.so.2 > >> #17 0xb72e996e in start_thread (arg=0xae1edb70) at > pthread_create.c:300 > >> #18 0xb7257a4e in clone () at > ../sysdeps/unix/sysv/linux/i386/clone.S:130 > >> (gdb) continue > >> Continuing. > >> [Thread 0xaddecb70 (LWP 6122) exited] > >> [Thread 0xae1edb70 (LWP 6121) exited] > >> [Thread 0xae7f0b70 (LWP 6120) exited] > >> [Thread 0xaedf3b70 (LWP 6119) exited] > >> [Thread 0xaf2f5b70 (LWP 6118) exited] > >> [Thread 0xaf7f7b70 (LWP 6117) exited] > >> [Thread 0xafbf8b70 (LWP 6116) exited] > >> [Thread 0xafff9b70 (LWP 6115) exited] > >> [Thread 0xb04fbb70 (LWP 6114) exited] > >> [Thread 0xb08fcb70 (LWP 6113) exited] > >> [Thread 0xb582ab70 (LWP 5868) exited] > >> [Thread 0xb5320b70 (LWP 5869) exited] > >> [Thread 0xb4e1eb70 (LWP 5870) exited] > >> [Thread 0xb4a1db70 (LWP 5871) exited] > >> [Thread 0xb461cb70 (LWP 5872) exited] > >> [Thread 0xb421bb70 (LWP 5873) exited] > >> [Thread 0xb5c2bb70 (LWP 5867) exited] > >> > >> Program terminated with signal SIGABRT, Aborted. > >> The program no longer exists. > >> (gdb) > >> > >> > > > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6964) ./configure bug when specifying openssl as the TLS library to use
by Howard Chu 08 Jun '11

08 Jun '11

I don't know where your configure script came from, but there's nothing related to OpenSSL at line 19408 of the current released configure script, and our script has had logic to detect -lrsaref since 1999. Closing this ITS. Use the actual configure script supplied by the OpenLDAP Project.

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by hyc＠symas.com 08 Jun '11

08 Jun '11

Howard Chu wrote: > Tyler Gates wrote: >> After applying the patches for ITS #6848 and ITS #6898 I still get crashes. >> Here's the latest: ??? neither #6848 nor #6898 are relevant to pcache. I think you should try the RE24 branch at this point, as a number of other pcache-related fixes have been merged there. > > Looks like a double-free. Can you reproduce this consistently? If so, what are > the steps? can you run slapd under valgrind and reproduce this? >> >> Program received signal SIGABRT, Aborted. >> [Switching to Thread 0xae1edb70 (LWP 6121)] >> 0xb76e2430 in __kernel_vsyscall () >> (gdb) >> (gdb) >> (gdb) bt >> #0 0xb76e2430 in __kernel_vsyscall () >> #1 0xb71b4651 in *__GI_raise (sig=6) at >> ../nptl/sysdeps/unix/sysv/linux/raise.c:64 >> #2 0xb71b7a82 in *__GI_abort () at abort.c:92 >> #3 0xb71eb49d in __libc_message (do_abort=2, fmt=0xb72bff98 "*** glibc >> detected *** %s: %s: 0x%s ***\n") at >> ../sysdeps/unix/sysv/linux/libc_fatal.c:189 >> #4 0xb71f5591 in malloc_printerr (action=<value optimized out>, str=0x6 >> <Address 0x6 out of bounds>, ptr=0xb9584e80) at malloc.c:6266 >> #5 0xb71f6de8 in _int_free (av=<value optimized out>, p=<value >> optimized out>) at malloc.c:4794 >> #6 0xb71f9ecd in *__GI___libc_free (mem=0xb9584e80) at malloc.c:3738 >> #7 0xb768ac20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2 >> #8 0xb768acaf in ber_bvarray_free_x () from /usr/lib/liblber-2.4.so.2 >> #9 0xb768acf5 in ber_bvarray_free () from /usr/lib/liblber-2.4.so.2 >> #10 0xb7743e5d in attr_clean (a=0xb6dcc06c) at >> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:148 >> #11 0xb7743efb in attrs_free (a=0xb6dcc06c) at >> /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:198 >> #12 0xb6d84b7f in hdb_cache_modify (bdb=0xb9536e10, e=0xb94f1dac, >> newAttrs=0xb6dd6884, txn=0xb2176970, lock=0xae1ec930) at cache.c:1238 >> #13 0xb6d7008c in hdb_modify (op=0xae1eccfc, rs=0xae1ecad0) at modify.c:662 >> #14 0xb6d52e81 in remove_query_data (op=<value optimized out>, >> query_uuid=<value optimized out>) >> at /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:1829 >> #15 0xb6d53d0b in consistency_check (ctx=0xae1ed1dc, arg=0xb955e018) at >> /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:3520 >> #16 0xb769d8b4 in ?? () from /usr/lib/libldap_r-2.4.so.2 >> #17 0xb72e996e in start_thread (arg=0xae1edb70) at pthread_create.c:300 >> #18 0xb7257a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 >> (gdb) continue >> Continuing. >> [Thread 0xaddecb70 (LWP 6122) exited] >> [Thread 0xae1edb70 (LWP 6121) exited] >> [Thread 0xae7f0b70 (LWP 6120) exited] >> [Thread 0xaedf3b70 (LWP 6119) exited] >> [Thread 0xaf2f5b70 (LWP 6118) exited] >> [Thread 0xaf7f7b70 (LWP 6117) exited] >> [Thread 0xafbf8b70 (LWP 6116) exited] >> [Thread 0xafff9b70 (LWP 6115) exited] >> [Thread 0xb04fbb70 (LWP 6114) exited] >> [Thread 0xb08fcb70 (LWP 6113) exited] >> [Thread 0xb582ab70 (LWP 5868) exited] >> [Thread 0xb5320b70 (LWP 5869) exited] >> [Thread 0xb4e1eb70 (LWP 5870) exited] >> [Thread 0xb4a1db70 (LWP 5871) exited] >> [Thread 0xb461cb70 (LWP 5872) exited] >> [Thread 0xb421bb70 (LWP 5873) exited] >> [Thread 0xb5c2bb70 (LWP 5867) exited] >> >> Program terminated with signal SIGABRT, Aborted. >> The program no longer exists. >> (gdb) >> >> > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by masarati＠aero.polimi.it 08 Jun '11

08 Jun '11

> masarati(a)aero.polimi.it wrote: >>> With your patch the response control is now decoded correctly and it >>> behaves >>> as expected for all operations except Modify DN Operation: >>> It returns empty value lists for all attributes no matter how >>> deleteoldrdn >>> is >>> set. The DN returned is correct. >> >> I suspect ors_attrsonly is set by mistake. Please try this: >> >> + myop.ors_attrsonly = 0; > > With your last patch everything works as expected now. Thanks a lot. Great. I've committed it. Thanks, p.

1 0

Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by michael＠stroeder.com 08 Jun '11

08 Jun '11

masarati(a)aero.polimi.it wrote: >> With your patch the response control is now decoded correctly and it >> behaves >> as expected for all operations except Modify DN Operation: >> It returns empty value lists for all attributes no matter how deleteoldrdn >> is >> set. The DN returned is correct. > > I suspect ors_attrsonly is set by mistake. Please try this: > > + myop.ors_attrsonly = 0; With your last patch everything works as expected now. Thanks a lot. Ciao, Michael.

1 0

Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by masarati＠aero.polimi.it 08 Jun '11

08 Jun '11

> Pierangelo Masarati wrote: >> On 06/07/2011 12:58 PM, michael(a)stroeder.com wrote: >>> Any chance this will be fixed? >>> >>> It would be very handy for sync processes to get back the entryUUID >>> generated >>> by OpenLDAP of a new entry in an AddResponse without having to read the >>> new >>> entry once more. >> >> If I get things right, what seems to be missing is a >> LDAP_RES_SEARCH_ENTRY tag >> right before encoding the search entry, something like > > [..patch snipped..] > > Thanks! > > With your patch the response control is now decoded correctly and it > behaves > as expected for all operations except Modify DN Operation: > It returns empty value lists for all attributes no matter how deleteoldrdn > is > set. The DN returned is correct. > > Here's the trace log from the Python script: > > ----------------------------- snip ----------------------------- > *** ldap://localhost:2071/ - SimpleLDAPObject.rename > (('uid=ablume,ou=Users,ou=schulung,dc=stroeder,dc=local', 'uid=ablume2', > None, > 0, [('1.3.6.1.1.13.2', True, '0\x06\x04\x01*\x04\x01+')], None),{}) > => result: 5 > *** ldap://localhost:2071/ - SimpleLDAPObject.result4 ((5, 1, -1, 0, 0, > 0),{}) > => result: (109, [], 5, [('1.3.6.1.1.13.2', 0, > 'd\x82\x01N\x045uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local0\x82\x01\x130\x07\x04\x03uid1\x000\x0f\x04\x0bobjectClass1\x000\r\x04\tuidNumber1\x000\r\x04\tgidNumber1\x000\x11\x04\rhomeDirectory1\x000\x06\x04\x02cn1\x000\x19\x04\x15structuralObjectClass1\x000\r\x04\tentryUUID1\x000\x10\x04\x0ccreatorsName1\x000\x13\x04\x0fcreateTimestamp1\x000\x0c\x04\x08entryCSN1\x000\x11\x04\rmodifiersName1\x000\x13\x04\x0fmodifyTimestamp1\x000\x0b\x04\x07entryDN1\x000\x15\x04\x11subschemaSubentry1\x000\x13\x04\x0fhasSubordinates1\x00')]) > resp_ctrls[0].dn: uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local > resp_ctrls[0].entry: > {'cn': [], > 'createTimestamp': [], > 'creatorsName': [], > 'entryCSN': [], > 'entryDN': [], > 'entryUUID': [], > 'gidNumber': [], > 'hasSubordinates': [], > 'homeDirectory': [], > 'modifiersName': [], > 'modifyTimestamp': [], > 'objectClass': [], > 'structuralObjectClass': [], > 'subschemaSubentry': [], > 'uid': [], > 'uidNumber': []} > ----------------------------- snip ----------------------------- I suspect ors_attrsonly is set by mistake. Please try this: --- a/servers/slapd/result.c +++ b/servers/slapd/result.c @@ -1042,7 +1042,8 @@ slap_send_search_entry( Operation *op, SlapReply *rs ) #endif if ( op->o_res_ber ) { /* read back control */ - rc = ber_printf( ber, "{O{" /*}}*/, &rs->sr_entry->e_name ); + rc = ber_printf( ber, "t{O{" /*}}*/, + LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name ); } else { rc = ber_printf( ber, "{it{O{" /*}}}*/, op->o_msgid, LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name ); @@ -1744,6 +1745,7 @@ int slap_read_controls( myop.o_res_ber = ber; myop.o_callback = NULL; myop.ors_slimit = 1; + myop.ors_attrsonly = 0; rc = slap_send_search_entry( &myop, rs ); if( rc ) return rc;

1 0

Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by michael＠stroeder.com 08 Jun '11

08 Jun '11

Pierangelo Masarati wrote: > On 06/07/2011 12:58 PM, michael(a)stroeder.com wrote: >> Any chance this will be fixed? >> >> It would be very handy for sync processes to get back the entryUUID generated >> by OpenLDAP of a new entry in an AddResponse without having to read the new >> entry once more. > > If I get things right, what seems to be missing is a LDAP_RES_SEARCH_ENTRY tag > right before encoding the search entry, something like > [..patch snipped..] Thanks! With your patch the response control is now decoded correctly and it behaves as expected for all operations except Modify DN Operation: It returns empty value lists for all attributes no matter how deleteoldrdn is set. The DN returned is correct. Here's the trace log from the Python script: ----------------------------- snip ----------------------------- *** ldap://localhost:2071/ - SimpleLDAPObject.rename (('uid=ablume,ou=Users,ou=schulung,dc=stroeder,dc=local', 'uid=ablume2', None, 0, [('1.3.6.1.1.13.2', True, '0\x06\x04\x01*\x04\x01+')], None),{}) => result: 5 *** ldap://localhost:2071/ - SimpleLDAPObject.result4 ((5, 1, -1, 0, 0, 0),{}) => result: (109, [], 5, [('1.3.6.1.1.13.2', 0, 'd\x82\x01N\x045uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local0\x82\x01\x130\x07\x04\x03uid1\x000\x0f\x04\x0bobjectClass1\x000\r\x04\tuidNumber1\x000\r\x04\tgidNumber1\x000\x11\x04\rhomeDirectory1\x000\x06\x04\x02cn1\x000\x19\x04\x15structuralObjectClass1\x000\r\x04\tentryUUID1\x000\x10\x04\x0ccreatorsName1\x000\x13\x04\x0fcreateTimestamp1\x000\x0c\x04\x08entryCSN1\x000\x11\x04\rmodifiersName1\x000\x13\x04\x0fmodifyTimestamp1\x000\x0b\x04\x07entryDN1\x000\x15\x04\x11subschemaSubentry1\x000\x13\x04\x0fhasSubordinates1\x00')]) resp_ctrls[0].dn: uid=ablume2,ou=Users,ou=schulung,dc=stroeder,dc=local resp_ctrls[0].entry: {'cn': [], 'createTimestamp': [], 'creatorsName': [], 'entryCSN': [], 'entryDN': [], 'entryUUID': [], 'gidNumber': [], 'hasSubordinates': [], 'homeDirectory': [], 'modifiersName': [], 'modifyTimestamp': [], 'objectClass': [], 'structuralObjectClass': [], 'subschemaSubentry': [], 'uid': [], 'uidNumber': []} ----------------------------- snip ----------------------------- Ciao, Michael.

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by hyc＠symas.com 08 Jun '11

08 Jun '11

Tyler Gates wrote: > After applying the patches for ITS #6848 and ITS #6898 I still get crashes. > Here's the latest: Looks like a double-free. Can you reproduce this consistently? If so, what are the steps? can you run slapd under valgrind and reproduce this? > > Program received signal SIGABRT, Aborted. > [Switching to Thread 0xae1edb70 (LWP 6121)] > 0xb76e2430 in __kernel_vsyscall () > (gdb) > (gdb) > (gdb) bt > #0 0xb76e2430 in __kernel_vsyscall () > #1 0xb71b4651 in *__GI_raise (sig=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #2 0xb71b7a82 in *__GI_abort () at abort.c:92 > #3 0xb71eb49d in __libc_message (do_abort=2, fmt=0xb72bff98 "*** glibc > detected *** %s: %s: 0x%s ***\n") at > ../sysdeps/unix/sysv/linux/libc_fatal.c:189 > #4 0xb71f5591 in malloc_printerr (action=<value optimized out>, str=0x6 > <Address 0x6 out of bounds>, ptr=0xb9584e80) at malloc.c:6266 > #5 0xb71f6de8 in _int_free (av=<value optimized out>, p=<value > optimized out>) at malloc.c:4794 > #6 0xb71f9ecd in *__GI___libc_free (mem=0xb9584e80) at malloc.c:3738 > #7 0xb768ac20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2 > #8 0xb768acaf in ber_bvarray_free_x () from /usr/lib/liblber-2.4.so.2 > #9 0xb768acf5 in ber_bvarray_free () from /usr/lib/liblber-2.4.so.2 > #10 0xb7743e5d in attr_clean (a=0xb6dcc06c) at > /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:148 > #11 0xb7743efb in attrs_free (a=0xb6dcc06c) at > /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:198 > #12 0xb6d84b7f in hdb_cache_modify (bdb=0xb9536e10, e=0xb94f1dac, > newAttrs=0xb6dd6884, txn=0xb2176970, lock=0xae1ec930) at cache.c:1238 > #13 0xb6d7008c in hdb_modify (op=0xae1eccfc, rs=0xae1ecad0) at modify.c:662 > #14 0xb6d52e81 in remove_query_data (op=<value optimized out>, > query_uuid=<value optimized out>) > at /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:1829 > #15 0xb6d53d0b in consistency_check (ctx=0xae1ed1dc, arg=0xb955e018) at > /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:3520 > #16 0xb769d8b4 in ?? () from /usr/lib/libldap_r-2.4.so.2 > #17 0xb72e996e in start_thread (arg=0xae1edb70) at pthread_create.c:300 > #18 0xb7257a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 > (gdb) continue > Continuing. > [Thread 0xaddecb70 (LWP 6122) exited] > [Thread 0xae1edb70 (LWP 6121) exited] > [Thread 0xae7f0b70 (LWP 6120) exited] > [Thread 0xaedf3b70 (LWP 6119) exited] > [Thread 0xaf2f5b70 (LWP 6118) exited] > [Thread 0xaf7f7b70 (LWP 6117) exited] > [Thread 0xafbf8b70 (LWP 6116) exited] > [Thread 0xafff9b70 (LWP 6115) exited] > [Thread 0xb04fbb70 (LWP 6114) exited] > [Thread 0xb08fcb70 (LWP 6113) exited] > [Thread 0xb582ab70 (LWP 5868) exited] > [Thread 0xb5320b70 (LWP 5869) exited] > [Thread 0xb4e1eb70 (LWP 5870) exited] > [Thread 0xb4a1db70 (LWP 5871) exited] > [Thread 0xb461cb70 (LWP 5872) exited] > [Thread 0xb421bb70 (LWP 5873) exited] > [Thread 0xb5c2bb70 (LWP 5867) exited] > > Program terminated with signal SIGABRT, Aborted. > The program no longer exists. > (gdb) > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6964) ./configure bug when specifying openssl as the TLS library to use
by the_uhu＠hotmail.com 08 Jun '11

08 Jun '11

Full_Name: Paul Rogers Version: 2.4.23 OS: Solaris 8 / 10 URL: Submission from: (NULL) (77.245.78.130) Objective: Compile OpenLDAP with SSL and TLS support against the latest OpenSSL library that is statically compiled so it is easier to port between secure systems. Operating System: Solaris 8 and 10, but could affect others (not tested). Compiled static libraries additional to the system: OpenSSL 0.9.8r Issue: When compiling OpenLDAP with openssl support for TLS / SSL, the configure script doesn't have a logic check to see if RSAglue and rsaref libraries should be used (now deprecated in OpenSSL) at line 19408. There are other places in configure where a check is made to see if $need_rsaref is set to yes. This needs applying to line 19408 also. Workaround: Manually change configure at line 19408 to LIBS="-lssl -lcrypto $LIBS" if you need to explicitly compile with OpenSSL TLS / SSL support. Evidence and command executed (from Solaris 10 but same thing occurred on Solaris 8 also): $ CC="/usr/sfw/bin/gcc" LIBS="-lssl -lcrypto -lresolv -lgen -lnsl -lsocket" LDFLAGS="-L/workingdir/openssl-0.9.8r/build-SOLARIS/usr/local/openssl-0.9.8r/lib -R/workingdir/openssl-0.9.8r/build-SOLARIS/usr/local/openssl-0.9.8r/lib" CPPFLAGS="-I/workingdir/openssl-0.9.8r/build-SOLARIS/usr/local/openssl-0.9.8r/include" ./configure --prefix=/workingdir/openldap-2.4.23/build-SOLARIS/usr/local/openldap-2.4.23 --disable-slapd --disable-shared --disable-dynamic --with-tls=openssl --with-ssl Configuring OpenLDAP 2.4.23-Release ... checking build system type... sparc-sun-solaris2.10 checking host system type... sparc-sun-solaris2.10 checking target system type... sparc-sun-solaris2.10 ... (other checks) ... checking struct sockaddr_storage... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_library_init in -lssl... no checking for ssl3_accept in -lssl... no configure: error: Could not locate TLS/SSL package

1 0

Re: (ITS#6878) ppcache segfault with tavl_delete
by tjgates＠castlebranch.com 08 Jun '11

08 Jun '11

After applying the patches for ITS #6848 and ITS #6898 I still get crashes. Here's the latest: Program received signal SIGABRT, Aborted. [Switching to Thread 0xae1edb70 (LWP 6121)] 0xb76e2430 in __kernel_vsyscall () (gdb) (gdb) (gdb) bt #0 0xb76e2430 in __kernel_vsyscall () #1 0xb71b4651 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb71b7a82 in *__GI_abort () at abort.c:92 #3 0xb71eb49d in __libc_message (do_abort=2, fmt=0xb72bff98 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #4 0xb71f5591 in malloc_printerr (action=<value optimized out>, str=0x6 <Address 0x6 out of bounds>, ptr=0xb9584e80) at malloc.c:6266 #5 0xb71f6de8 in _int_free (av=<value optimized out>, p=<value optimized out>) at malloc.c:4794 #6 0xb71f9ecd in *__GI___libc_free (mem=0xb9584e80) at malloc.c:3738 #7 0xb768ac20 in ber_memfree_x () from /usr/lib/liblber-2.4.so.2 #8 0xb768acaf in ber_bvarray_free_x () from /usr/lib/liblber-2.4.so.2 #9 0xb768acf5 in ber_bvarray_free () from /usr/lib/liblber-2.4.so.2 #10 0xb7743e5d in attr_clean (a=0xb6dcc06c) at /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:148 #11 0xb7743efb in attrs_free (a=0xb6dcc06c) at /tmp/buildd/openldap-2.4.25/servers/slapd/attr.c:198 #12 0xb6d84b7f in hdb_cache_modify (bdb=0xb9536e10, e=0xb94f1dac, newAttrs=0xb6dd6884, txn=0xb2176970, lock=0xae1ec930) at cache.c:1238 #13 0xb6d7008c in hdb_modify (op=0xae1eccfc, rs=0xae1ecad0) at modify.c:662 #14 0xb6d52e81 in remove_query_data (op=<value optimized out>, query_uuid=<value optimized out>) at /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:1829 #15 0xb6d53d0b in consistency_check (ctx=0xae1ed1dc, arg=0xb955e018) at /tmp/buildd/openldap-2.4.25/servers/slapd/overlays/pcache.c:3520 #16 0xb769d8b4 in ?? () from /usr/lib/libldap_r-2.4.so.2 #17 0xb72e996e in start_thread (arg=0xae1edb70) at pthread_create.c:300 #18 0xb7257a4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (gdb) continue Continuing. [Thread 0xaddecb70 (LWP 6122) exited] [Thread 0xae1edb70 (LWP 6121) exited] [Thread 0xae7f0b70 (LWP 6120) exited] [Thread 0xaedf3b70 (LWP 6119) exited] [Thread 0xaf2f5b70 (LWP 6118) exited] [Thread 0xaf7f7b70 (LWP 6117) exited] [Thread 0xafbf8b70 (LWP 6116) exited] [Thread 0xafff9b70 (LWP 6115) exited] [Thread 0xb04fbb70 (LWP 6114) exited] [Thread 0xb08fcb70 (LWP 6113) exited] [Thread 0xb582ab70 (LWP 5868) exited] [Thread 0xb5320b70 (LWP 5869) exited] [Thread 0xb4e1eb70 (LWP 5870) exited] [Thread 0xb4a1db70 (LWP 5871) exited] [Thread 0xb461cb70 (LWP 5872) exited] [Thread 0xb421bb70 (LWP 5873) exited] [Thread 0xb5c2bb70 (LWP 5867) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated.

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by masarati＠aero.polimi.it 07 Jun '11

07 Jun '11

The problem seems to be that unique_modify() calls unique_search() passing it an Operation that contains the assertion, which fails within the search. The failure is propagated back to the modification. The assertion control should not apply to internal operations performed by the unique overlay. The solution to me is not straightforward, apart from explicitly removing the assert control when calling unique_search(). I understand this solution is by no means general; similar problems may surface in other overlays and with other controls. p.

1 0

Re: (ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by hyc＠symas.com 07 Jun '11

07 Jun '11

Tyler Gates wrote: > Howard, > Does the most recent patch to ITS #6948 'ITS#6948 partial revert > of #6837, unnecessary' replace the first patch 'ITS#6948 fix ITS#6837 > patch' ? No. > On Sun, Jun 5, 2011 at 10:04 PM, Tyler Gates<tgates81(a)gmail.com> wrote: >> Thanks Howard, it working perfectly again. This also resolves my other >> ITS, #6891. >> >> On 06/05/2011 04:36 PM, Howard Chu wrote: >>> tgates81(a)gmail.com wrote: >>>> Full_Name: Tyler Gates >>>> Version: 2.4.25 >>>> OS: Ubuntu 10.04 LTS >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (65.184.61.44) >>>> >>>> >>>> I've been fighting with a strange issue related to a backend database >>>> using a >>>> pcache configuration since upgrading from 2.4.24 to 2.4.25. Assuming >>>> there was >>>> just something wrong with my cn=config I decided to start back fresh >>>> using >>>> slapd.conf instead. >>>> Once I got the config working just fine I used slaptest to convert >>>> the config to >>>> a new cn=config. Unfortunately when I tried using -F cn=config >>>> instead of my -f >>>> slapd.conf, slapd failed with the same old message: >>> >>> Looks like this was broken by the patch for ITS#6837. Working on a new >>> fix. >>>> >>>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup: warning, >>>> database 0 (hdb) has no suffix >>>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one: >>>> starting >>>> "(unknown)" >>>> May 22 09:15:58 directory-proxy2 slapd[25055]: hdb_db_open: need suffix. >>>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one >>>> (type=hdb, >>>> suffix="(null)"): bi_db_open failed! (-1) >>>> May 22 09:15:58 directory-proxy2 slapd[25055]: slapd shutdown: initiated >>>> >>>> >>>> The backend database has never required me specify a suffix since it >>>> is already >>>> specified in the ldap overlay and when I try to add it in I get slapd >>>> trying to >>>> open the database twice which results in the second instance having >>>> access >>>> issues thus rendering all of the database inaccessible to queries. >>>> >>>> I'm assuming there has been a configuration change in cn=config for this >>>> particular layout but slaptest has not been updated. Below is a copy >>>> of the flat >>>> file I used that worked fine but failed once converted to cn=config >>>> using >>>> slaptest -f slapd.conf -F /etc/ldap/slapd.d/ >>>> >>>> root@directory-proxy:~# grep "^[^#]" >>>> /etc/ldap/slapd.conf.back_ldap_ppcache >>>> include /etc/ldap/schema/core.schema >>>> include /etc/ldap/schema/cosine.schema >>>> include /etc/ldap/schema/nis.schema >>>> include /etc/ldap/schema/inetorgperson.schema >>>> include /etc/ldap/schema/openldap.schema >>>> include /etc/ldap/schema/sudo.schema >>>> include /etc/ldap/schema/autofs.schema >>>> include /etc/ldap/schema/ppolicy.schema >>>> include /etc/ldap/schema/qmail.schema >>>> include /etc/ldap/schema/puppet.schema >>>> pidfile /var/run/slapd/slapd.pid >>>> argsfile /var/run/slapd/slapd.args >>>> modulepath /usr/lib/ldap >>>> moduleload back_ldap >>>> moduleload back_hdb >>>> moduleload pcache >>>> moduleload ppolicy >>>> TLSCertificateFile /etc/ldap/ssl/slapd.crt >>>> TLSCertificateKeyFile /etc/ldap/ssl/slapd.key >>>> TLSCACertificateFile /etc/ssl/certs/ca.castlebranch.com.crt >>>> loglevel -1 >>>> allow bind_anon_dn >>>> database config >>>> rootdn cn=admin,cn=config >>>> rootpw secret >>>> access to * by >>>> dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >>>> manage by * break >>>> database ldap >>>> suffix "dc=domain,dc=com" >>>> rootdn "cn=Manager,dc=domain,dc=com" >>>> rootpw secret >>>> uri "ldaps://directory1.domain.com >>>> ldaps://directory2.domain.com" >>>> overlay pcache >>>> proxycache hdb 100000 3 1000 100 >>>> proxyAttrset 0 uid userPassword uidNumber gidNumber cn homeDirectory >>>> loginShell gecos description memberUid uniqueMember objectClass >>>> proxyAttrset 1 cn automountInformation >>>> proxyAttrset 2 cn mail >>>> proxyTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 >>>> proxyTemplate (&(objectClass=)(uid=)) 0 1800 >>>> proxyTemplate (&(objectClass=)(cn=)) 0 1800 >>>> proxyTemplate (&(objectClass=)) 0 1800 >>>> proxyTemplate (objectClass=) 0 1800 >>>> proxyTemplate (&(objectClass=)(memberUid=)) 0 1800 900 >>>> proxyTemplate (&(objectClass=)(uniqueMember=)) 0 1800 900 >>>> proxyTemplate (&(objectClass=)(uidNumber=)) 0 1800 >>>> proxyTemplate (&(objectClass=)(gidNumber=)) 0 1800 >>>> proxyTemplate (&(objectClass=)(|(cn=)(gidNumber=))) 1 3600 600 >>>> proxyTemplate (&(objectClass=)(|(cn=)(cn=))) 1 3600 600 >>>> proxyTemplate (&(objectClass=)(|(cn=)(cn=)(cn=))) 1 3600 600 >>>> proxyTemplate (|(cn=)(mail=)(sn=)) 2 7200 >>>> directory /var/lib/ldap >>>> cachesize 1000 >>>> idletimeout 600 >>>> idlcachesize 3000 >>>> index objectClass eq >>>> index cn,mail,surname,givenname eq,subinitial >>>> index uidNumber,gidNumber,memberuid,member,uniqueMember eq >>>> index uid eq,subinitial >>>> index nisMapName,automountInformation eq >>>> index userPassword,homeDirectory,loginShell,gecos,description eq >>>> index pcacheQueryID eq >>>> >>>> >>> >>> >> > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by tgates81＠gmail.com 07 Jun '11

07 Jun '11

Howard, Does the most recent patch to ITS #6948 'ITS#6948 partial revert of #6837, unnecessary' replace the first patch 'ITS#6948 fix ITS#6837 patch' ? On Sun, Jun 5, 2011 at 10:04 PM, Tyler Gates <tgates81(a)gmail.com> wrote: > Thanks Howard, it working perfectly again. This also resolves my other > ITS, #6891. > > On 06/05/2011 04:36 PM, Howard Chu wrote: >> tgates81(a)gmail.com wrote: >>> Full_Name: Tyler Gates >>> Version: 2.4.25 >>> OS: Ubuntu 10.04 LTS >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (65.184.61.44) >>> >>> >>> I've been fighting with a strange issue related to a backend database >>> using a >>> pcache configuration since upgrading from 2.4.24 to 2.4.25. Assuming >>> there was >>> just something wrong with my cn=config I decided to start back fresh >>> using >>> slapd.conf instead. >>> Once I got the config working just fine I used slaptest to convert >>> the config to >>> a new cn=config. Unfortunately when I tried using -F cn=config >>> instead of my -f >>> slapd.conf, slapd failed with the same old message: >> >> Looks like this was broken by the patch for ITS#6837. Working on a new >> fix. >>> >>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup: warning, >>> database 0 (hdb) has no suffix >>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one: >>> starting >>> "(unknown)" >>> May 22 09:15:58 directory-proxy2 slapd[25055]: hdb_db_open: need suffix. >>> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one >>> (type=hdb, >>> suffix="(null)"): bi_db_open failed! (-1) >>> May 22 09:15:58 directory-proxy2 slapd[25055]: slapd shutdown: initiated >>> >>> >>> The backend database has never required me specify a suffix since it >>> is already >>> specified in the ldap overlay and when I try to add it in I get slapd >>> trying to >>> open the database twice which results in the second instance having >>> access >>> issues thus rendering all of the database inaccessible to queries. >>> >>> I'm assuming there has been a configuration change in cn=config for this >>> particular layout but slaptest has not been updated. Below is a copy >>> of the flat >>> file I used that worked fine but failed once converted to cn=config >>> using >>> slaptest -f slapd.conf -F /etc/ldap/slapd.d/ >>> >>> root@directory-proxy:~# grep "^[^#]" >>> /etc/ldap/slapd.conf.back_ldap_ppcache >>> include /etc/ldap/schema/core.schema >>> include /etc/ldap/schema/cosine.schema >>> include /etc/ldap/schema/nis.schema >>> include /etc/ldap/schema/inetorgperson.schema >>> include /etc/ldap/schema/openldap.schema >>> include /etc/ldap/schema/sudo.schema >>> include /etc/ldap/schema/autofs.schema >>> include /etc/ldap/schema/ppolicy.schema >>> include /etc/ldap/schema/qmail.schema >>> include /etc/ldap/schema/puppet.schema >>> pidfile /var/run/slapd/slapd.pid >>> argsfile /var/run/slapd/slapd.args >>> modulepath /usr/lib/ldap >>> moduleload back_ldap >>> moduleload back_hdb >>> moduleload pcache >>> moduleload ppolicy >>> TLSCertificateFile /etc/ldap/ssl/slapd.crt >>> TLSCertificateKeyFile /etc/ldap/ssl/slapd.key >>> TLSCACertificateFile /etc/ssl/certs/ca.castlebranch.com.crt >>> loglevel -1 >>> allow bind_anon_dn >>> database config >>> rootdn cn=admin,cn=config >>> rootpw secret >>> access to * by >>> dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >>> manage by * break >>> database ldap >>> suffix "dc=domain,dc=com" >>> rootdn "cn=Manager,dc=domain,dc=com" >>> rootpw secret >>> uri "ldaps://directory1.domain.com >>> ldaps://directory2.domain.com" >>> overlay pcache >>> proxycache hdb 100000 3 1000 100 >>> proxyAttrset 0 uid userPassword uidNumber gidNumber cn homeDirectory >>> loginShell gecos description memberUid uniqueMember objectClass >>> proxyAttrset 1 cn automountInformation >>> proxyAttrset 2 cn mail >>> proxyTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 >>> proxyTemplate (&(objectClass=)(uid=)) 0 1800 >>> proxyTemplate (&(objectClass=)(cn=)) 0 1800 >>> proxyTemplate (&(objectClass=)) 0 1800 >>> proxyTemplate (objectClass=) 0 1800 >>> proxyTemplate (&(objectClass=)(memberUid=)) 0 1800 900 >>> proxyTemplate (&(objectClass=)(uniqueMember=)) 0 1800 900 >>> proxyTemplate (&(objectClass=)(uidNumber=)) 0 1800 >>> proxyTemplate (&(objectClass=)(gidNumber=)) 0 1800 >>> proxyTemplate (&(objectClass=)(|(cn=)(gidNumber=))) 1 3600 600 >>> proxyTemplate (&(objectClass=)(|(cn=)(cn=))) 1 3600 600 >>> proxyTemplate (&(objectClass=)(|(cn=)(cn=)(cn=))) 1 3600 600 >>> proxyTemplate (|(cn=)(mail=)(sn=)) 2 7200 >>> directory /var/lib/ldap >>> cachesize 1000 >>> idletimeout 600 >>> idlcachesize 3000 >>> index objectClass eq >>> index cn,mail,surname,givenname eq,subinitial >>> index uidNumber,gidNumber,memberuid,member,uniqueMember eq >>> index uid eq,subinitial >>> index nisMapName,automountInformation eq >>> index userPassword,homeDirectory,loginShell,gecos,description eq >>> index pcacheQueryID eq >>> >>> >> >> >

1 0

Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by masarati＠aero.polimi.it 07 Jun '11

07 Jun '11

On 06/07/2011 12:58 PM, michael(a)stroeder.com wrote: > Any chance this will be fixed? > > It would be very handy for sync processes to get back the entryUUID generated > by OpenLDAP of a new entry in an AddResponse without having to read the new > entry once more. If I get things right, what seems to be missing is a LDAP_RES_SEARCH_ENTRY tag right before encoding the search entry, something like diff --git a/servers/slapd/result.c b/servers/slapd/result.c index 0803f7f..3a21fb5 100644 --- a/servers/slapd/result.c +++ b/servers/slapd/result.c @@ -1042,7 +1042,8 @@ slap_send_search_entry( Operation *op, SlapReply *rs ) #endif if ( op->o_res_ber ) { /* read back control */ - rc = ber_printf( ber, "{O{" /*}}*/, &rs->sr_entry->e_name ); + rc = ber_printf( ber, "t{O{" /*}}*/, + LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name ); } else { rc = ber_printf( ber, "{it{O{" /*}}}*/, op->o_msgid, LDAP_RES_SEARCH_ENTRY, &rs->sr_entry->e_name ); but I'd like to have some feedback. p.

1 0

Re: (ITS#6899) Read Entry Control response value is not compliant to definition of SearchResultEntry
by michael＠stroeder.com 07 Jun '11

07 Jun '11

Any chance this will be fixed? It would be very handy for sync processes to get back the entryUUID generated by OpenLDAP of a new entry in an AddResponse without having to read the new entry once more.

1 0

Re: (ITS#6940) issues reading the db directory since 2.4.25
by tjgates＠castlebranch.com 06 Jun '11

06 Jun '11

This has been fixed in MASTER and can be closed: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=6e0934d5… -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated.

1 0

Re: (ITS#6888) slapd 2.4.23 terminating with 'SIGABRT'
by hyc＠symas.com 06 Jun '11

06 Jun '11

jwebb(a)localnet.com wrote: > The reason we are running 5 clients (each with 10 threads) performing > concurrent wildcard searches on "unindexed attributes", is purely and > simply.... load testing. > > the test seems reasonable enough that (with our current configuration) > slapd should be able to handle it with terminating with a 'SIGABRT'... > > am i wrong in assuming this? Your trace shows an abort because malloc failed, meaning your system was out of RAM. Regardless of what "free" reports, your malloc library ran out of space. There's no OpenLDAP bug here, closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by tgates81＠gmail.com 05 Jun '11

05 Jun '11

Thanks Howard, it working perfectly again. This also resolves my other ITS, #6891. On 06/05/2011 04:36 PM, Howard Chu wrote: > tgates81(a)gmail.com wrote: >> Full_Name: Tyler Gates >> Version: 2.4.25 >> OS: Ubuntu 10.04 LTS >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (65.184.61.44) >> >> >> I've been fighting with a strange issue related to a backend database >> using a >> pcache configuration since upgrading from 2.4.24 to 2.4.25. Assuming >> there was >> just something wrong with my cn=config I decided to start back fresh >> using >> slapd.conf instead. >> Once I got the config working just fine I used slaptest to convert >> the config to >> a new cn=config. Unfortunately when I tried using -F cn=config >> instead of my -f >> slapd.conf, slapd failed with the same old message: > > Looks like this was broken by the patch for ITS#6837. Working on a new > fix. >> >> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup: warning, >> database 0 (hdb) has no suffix >> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one: >> starting >> "(unknown)" >> May 22 09:15:58 directory-proxy2 slapd[25055]: hdb_db_open: need suffix. >> May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one >> (type=hdb, >> suffix="(null)"): bi_db_open failed! (-1) >> May 22 09:15:58 directory-proxy2 slapd[25055]: slapd shutdown: initiated >> >> >> The backend database has never required me specify a suffix since it >> is already >> specified in the ldap overlay and when I try to add it in I get slapd >> trying to >> open the database twice which results in the second instance having >> access >> issues thus rendering all of the database inaccessible to queries. >> >> I'm assuming there has been a configuration change in cn=config for this >> particular layout but slaptest has not been updated. Below is a copy >> of the flat >> file I used that worked fine but failed once converted to cn=config >> using >> slaptest -f slapd.conf -F /etc/ldap/slapd.d/ >> >> root@directory-proxy:~# grep "^[^#]" >> /etc/ldap/slapd.conf.back_ldap_ppcache >> include /etc/ldap/schema/core.schema >> include /etc/ldap/schema/cosine.schema >> include /etc/ldap/schema/nis.schema >> include /etc/ldap/schema/inetorgperson.schema >> include /etc/ldap/schema/openldap.schema >> include /etc/ldap/schema/sudo.schema >> include /etc/ldap/schema/autofs.schema >> include /etc/ldap/schema/ppolicy.schema >> include /etc/ldap/schema/qmail.schema >> include /etc/ldap/schema/puppet.schema >> pidfile /var/run/slapd/slapd.pid >> argsfile /var/run/slapd/slapd.args >> modulepath /usr/lib/ldap >> moduleload back_ldap >> moduleload back_hdb >> moduleload pcache >> moduleload ppolicy >> TLSCertificateFile /etc/ldap/ssl/slapd.crt >> TLSCertificateKeyFile /etc/ldap/ssl/slapd.key >> TLSCACertificateFile /etc/ssl/certs/ca.castlebranch.com.crt >> loglevel -1 >> allow bind_anon_dn >> database config >> rootdn cn=admin,cn=config >> rootpw secret >> access to * by >> dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >> manage by * break >> database ldap >> suffix "dc=domain,dc=com" >> rootdn "cn=Manager,dc=domain,dc=com" >> rootpw secret >> uri "ldaps://directory1.domain.com >> ldaps://directory2.domain.com" >> overlay pcache >> proxycache hdb 100000 3 1000 100 >> proxyAttrset 0 uid userPassword uidNumber gidNumber cn homeDirectory >> loginShell gecos description memberUid uniqueMember objectClass >> proxyAttrset 1 cn automountInformation >> proxyAttrset 2 cn mail >> proxyTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 >> proxyTemplate (&(objectClass=)(uid=)) 0 1800 >> proxyTemplate (&(objectClass=)(cn=)) 0 1800 >> proxyTemplate (&(objectClass=)) 0 1800 >> proxyTemplate (objectClass=) 0 1800 >> proxyTemplate (&(objectClass=)(memberUid=)) 0 1800 900 >> proxyTemplate (&(objectClass=)(uniqueMember=)) 0 1800 900 >> proxyTemplate (&(objectClass=)(uidNumber=)) 0 1800 >> proxyTemplate (&(objectClass=)(gidNumber=)) 0 1800 >> proxyTemplate (&(objectClass=)(|(cn=)(gidNumber=))) 1 3600 600 >> proxyTemplate (&(objectClass=)(|(cn=)(cn=))) 1 3600 600 >> proxyTemplate (&(objectClass=)(|(cn=)(cn=)(cn=))) 1 3600 600 >> proxyTemplate (|(cn=)(mail=)(sn=)) 2 7200 >> directory /var/lib/ldap >> cachesize 1000 >> idletimeout 600 >> idlcachesize 3000 >> index objectClass eq >> index cn,mail,surname,givenname eq,subinitial >> index uidNumber,gidNumber,memberuid,member,uniqueMember eq >> index uid eq,subinitial >> index nisMapName,automountInformation eq >> index userPassword,homeDirectory,loginShell,gecos,description eq >> index pcacheQueryID eq >> >> > >

1 0

Re: (ITS#6891)
by tgates81＠gmail.com 05 Jun '11

05 Jun '11

This is now fixed with ITS 6948 patch. On 04/12/2011 03:42 PM, Quanah Gibson-Mount wrote: > --On Tuesday, April 12, 2011 3:04 PM -0400 Tyler Gates > <tgates81(a)gmail.com> wrote: > >> I can't get a back trace because it doesn't crash under gdb, slapd >> only responds to queries with error: >> >> client: >> result: 80 Other (e.g., implementation specific) error >> text: internal error >> server: >> bdb(dc=example,dc=com): PANIC: fatal region error detected; run >> recovery >> >> Apr 12 14:25:34 directory-proxy2 slapd[2526]: backend_startup_one >> (type=hdb, suffix="(null)"): bi_db_open failed! (-1) > > These all indicate permissions issues. It sounds like the slapd > instance does not have permissions to access the database. > > --Quanah > > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by hyc＠symas.com 05 Jun '11

05 Jun '11

tgates81(a)gmail.com wrote: > Full_Name: Tyler Gates > Version: 2.4.25 > OS: Ubuntu 10.04 LTS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.184.61.44) > > > I've been fighting with a strange issue related to a backend database using a > pcache configuration since upgrading from 2.4.24 to 2.4.25. Assuming there was > just something wrong with my cn=config I decided to start back fresh using > slapd.conf instead. > Once I got the config working just fine I used slaptest to convert the config to > a new cn=config. Unfortunately when I tried using -F cn=config instead of my -f > slapd.conf, slapd failed with the same old message: Looks like this was broken by the patch for ITS#6837. Working on a new fix. > > May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup: warning, > database 0 (hdb) has no suffix > May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one: starting > "(unknown)" > May 22 09:15:58 directory-proxy2 slapd[25055]: hdb_db_open: need suffix. > May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one (type=hdb, > suffix="(null)"): bi_db_open failed! (-1) > May 22 09:15:58 directory-proxy2 slapd[25055]: slapd shutdown: initiated > > > The backend database has never required me specify a suffix since it is already > specified in the ldap overlay and when I try to add it in I get slapd trying to > open the database twice which results in the second instance having access > issues thus rendering all of the database inaccessible to queries. > > I'm assuming there has been a configuration change in cn=config for this > particular layout but slaptest has not been updated. Below is a copy of the flat > file I used that worked fine but failed once converted to cn=config using > slaptest -f slapd.conf -F /etc/ldap/slapd.d/ > > root@directory-proxy:~# grep "^[^#]" /etc/ldap/slapd.conf.back_ldap_ppcache > include /etc/ldap/schema/core.schema > include /etc/ldap/schema/cosine.schema > include /etc/ldap/schema/nis.schema > include /etc/ldap/schema/inetorgperson.schema > include /etc/ldap/schema/openldap.schema > include /etc/ldap/schema/sudo.schema > include /etc/ldap/schema/autofs.schema > include /etc/ldap/schema/ppolicy.schema > include /etc/ldap/schema/qmail.schema > include /etc/ldap/schema/puppet.schema > pidfile /var/run/slapd/slapd.pid > argsfile /var/run/slapd/slapd.args > modulepath /usr/lib/ldap > moduleload back_ldap > moduleload back_hdb > moduleload pcache > moduleload ppolicy > TLSCertificateFile /etc/ldap/ssl/slapd.crt > TLSCertificateKeyFile /etc/ldap/ssl/slapd.key > TLSCACertificateFile /etc/ssl/certs/ca.castlebranch.com.crt > loglevel -1 > allow bind_anon_dn > database config > rootdn cn=admin,cn=config > rootpw secret > access to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > manage by * break > database ldap > suffix "dc=domain,dc=com" > rootdn "cn=Manager,dc=domain,dc=com" > rootpw secret > uri "ldaps://directory1.domain.com ldaps://directory2.domain.com" > overlay pcache > proxycache hdb 100000 3 1000 100 > proxyAttrset 0 uid userPassword uidNumber gidNumber cn homeDirectory > loginShell gecos description memberUid uniqueMember objectClass > proxyAttrset 1 cn automountInformation > proxyAttrset 2 cn mail > proxyTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 > proxyTemplate (&(objectClass=)(uid=)) 0 1800 > proxyTemplate (&(objectClass=)(cn=)) 0 1800 > proxyTemplate (&(objectClass=)) 0 1800 > proxyTemplate (objectClass=) 0 1800 > proxyTemplate (&(objectClass=)(memberUid=)) 0 1800 900 > proxyTemplate (&(objectClass=)(uniqueMember=)) 0 1800 900 > proxyTemplate (&(objectClass=)(uidNumber=)) 0 1800 > proxyTemplate (&(objectClass=)(gidNumber=)) 0 1800 > proxyTemplate (&(objectClass=)(|(cn=)(gidNumber=))) 1 3600 600 > proxyTemplate (&(objectClass=)(|(cn=)(cn=))) 1 3600 600 > proxyTemplate (&(objectClass=)(|(cn=)(cn=)(cn=))) 1 3600 600 > proxyTemplate (|(cn=)(mail=)(sn=)) 2 7200 > directory /var/lib/ldap > cachesize 1000 > idletimeout 600 > idlcachesize 3000 > index objectClass eq > index cn,mail,surname,givenname eq,subinitial > index uidNumber,gidNumber,memberuid,member,uniqueMember eq > index uid eq,subinitial > index nisMapName,automountInformation eq > index userPassword,homeDirectory,loginShell,gecos,description eq > index pcacheQueryID eq > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by michael＠stroeder.com 05 Jun '11

05 Jun '11

Sad enough I had to turn off using the assertion control in upcoming web2ldap release as yet another vendor-specific workaround - this time for OpenLDAP... It works with OpenDS and OpenDJ and web2ldap uses it with these servers.

1 0

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by michael＠stroeder.com 05 Jun '11

05 Jun '11

hyc(a)symas.com wrote: > Fixed now. 60+ test iterations without error. Ciao, Michael.

1 0

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by hyc＠symas.com 04 Jun '11

04 Jun '11

hyc(a)symas.com wrote: > Howard Chu wrote: > Ah this is a simple timing issue in the test startup; the incoming entry was > ignored because its entryCSN was older than the local one. > >> (back-config explicitly prevents any attempts to delete both of these entries. >> When syncrepl fails to delete an entry, it does a modify to change the >> objectclass to glue, which explains how they got to their final state when the >> test aborted.) > > I guess we can try to patch the startup sequencing of the script; this problem > can only occur in cn=config, because of the special nature of the cn=schema > and olcDatabase={0}config entries. > Fixed now. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by hyc＠symas.com 04 Jun '11

04 Jun '11

Howard Chu wrote: > michael(a)stroeder.com wrote: >> BTW: This is git master (formerly known as HEAD). >> >> See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz > > I see, and I was also able to reproduce it here. The difference is that on > server2, 2 of the entries have objectClass: glue instead of their correct > objectclasses. From the diffs, this affected cn=schema,cn=config and > olcDatabase={0}config,cn=config. Looking at the logs, this happened because > during a syncrepl_nonpresent pass, the UUIDs for these two entries didn't > match the UUIDs sent from some other master, so syncrepl attempted to delete them. > > Generally this is normal - cn=schema,cn=config and olcDatabase={0},cn=config > are always created automatically by each slapd, so naturally their UUIDs > differ on each server. But, also generally, after the first refresh each > consumer would modify their local entries and overwrite the UUIDs with the > ones received from their provider. Not sure why this didn't happen this time > around. Ah this is a simple timing issue in the test startup; the incoming entry was ignored because its entryCSN was older than the local one. > (back-config explicitly prevents any attempts to delete both of these entries. > When syncrepl fails to delete an entry, it does a modify to change the > objectclass to glue, which explains how they got to their final state when the > test aborted.) I guess we can try to patch the startup sequencing of the script; this problem can only occur in cn=config, because of the special nature of the cn=schema and olcDatabase={0}config entries. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by hyc＠symas.com 04 Jun '11

04 Jun '11

michael(a)stroeder.com wrote: > BTW: This is git master (formerly known as HEAD). > > See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz I see, and I was also able to reproduce it here. The difference is that on server2, 2 of the entries have objectClass: glue instead of their correct objectclasses. From the diffs, this affected cn=schema,cn=config and olcDatabase={0}config,cn=config. Looking at the logs, this happened because during a syncrepl_nonpresent pass, the UUIDs for these two entries didn't match the UUIDs sent from some other master, so syncrepl attempted to delete them. Generally this is normal - cn=schema,cn=config and olcDatabase={0},cn=config are always created automatically by each slapd, so naturally their UUIDs differ on each server. But, also generally, after the first refresh each consumer would modify their local entries and overwrite the UUIDs with the ones received from their provider. Not sure why this didn't happen this time around. (back-config explicitly prevents any attempts to delete both of these entries. When syncrepl fails to delete an entry, it does a modify to change the objectclass to glue, which explains how they got to their final state when the test aborted.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by michael＠stroeder.com 04 Jun '11

04 Jun '11

Howard Chu wrote: > michael(a)stroeder.com wrote: >> BTW: This is git master (formerly known as HEAD). >> >> See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz > > I have the test running now, will see how it goes. It's probably a good idea > to include the git commit ID now instead of just referencing master/HEAD . I always do git pull before posting an ITS applying HEAD to make sure nothing came in after the error. Ciao, Michael.

1 0

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by hyc＠symas.com 04 Jun '11

04 Jun '11

michael(a)stroeder.com wrote: > BTW: This is git master (formerly known as HEAD). > > See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz I have the test running now, will see how it goes. It's probably a good idea to include the git commit ID now instead of just referencing master/HEAD . -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6963) test050: test failed - server 1 and server 2 configs differ
by michael＠stroeder.com 04 Jun '11

04 Jun '11

BTW: This is git master (formerly known as HEAD). See also: http://www.stroeder.com/temp/openldap-its-6963-testrun.tar.gz

1 0

(ITS#6963) test050: test failed - server 1 and server 2 configs differ
by michael＠stroeder.com 04 Jun '11

04 Jun '11

Full_Name: Version: OS: URL: Submission from: (NULL) (84.163.63.172) test050 occasionally fails... $ ./run -l 100 -b bdb test050 [..] Cleaning up test run directory from this run. Running 19 of 100 iterations running defines.sh Initializing server configurations... Starting server 1 on TCP/IP port 9011... Using ldapsearch to check that server 1 is running... Inserting syncprov overlay on server 1... Starting server 2 on TCP/IP port 9012... Using ldapsearch to check that server 2 is running... Configuring syncrepl on server 2... Starting server 3 on TCP/IP port 9013... Using ldapsearch to check that server 3 is running... Configuring syncrepl on server 3... Starting server 4 on TCP/IP port 9014... Using ldapsearch to check that server 4 is running... Configuring syncrepl on server 4... Adding schema and databases on server 1... Using ldapadd to populate server 1... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read config from server 1... Using ldapsearch to read config from server 2... Using ldapsearch to read config from server 3... Using ldapsearch to read config from server 4... Comparing retrieved configs from server 1 and server 2... test failed - server 1 and server 2 configs differ

1 0

Re: (ITS#6947) ldapadd crashes with LDIFs with invalid line termination
by jvcelak＠redhat.com 04 Jun '11

04 Jun '11

> > adding entries to LDAP database from file using ldapadd tool causes > > memory > > corruption error, when the last line of the input file is not > > terminated by '\n' > > character. > > Don't do that. I agree. But the tool should not crash on invalid output anyway. > > I am attaching proposed patch, which fixes this issue. > > The patch uses a GNU-specific function. Since GLIBC is not supported > on all of > the platforms OpenLDAP supports, the patch is not acceptable as-is. Sorry, I missed that. I will fix it and resend the patch. Jan

1 0

Re: (ITS#6946) ldapexop: ber_free_buf: Assertion failed
by hyc＠symas.com 03 Jun '11

03 Jun '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-110519-ldapexop-double-free.patch > Submission from: (NULL) (209.132.186.34) > > > Hello. > > A problem with crashing ldapexop was reported to our bugzilla. All versions > since 2.4.24 are affected. It seems that the bug was introduced by following > change in ldapexop.c. > > http://www.openldap.org/devel/cvsweb.cgi/clients/tools/ldapexop.c.diff?r1=1… > > Easy to reproduce. With clean configuration run: > $ ldapexop -H ldap:// -x whoami > anonymous > ldapexop: ../../../libraries/liblber/io.c:186: ber_free_buf: Assertion > `((ber)->ber_opts.lbo_valid==0x2)' failed. > Aborted > > Complete steps to reproduce in Fedora are specified in the original bugreport: > https://bugzilla.redhat.com/show_bug.cgi?id=699683 > > I think it is cause by double freeing the result. I am attaching a proposed > patch. Please, review my change. > > Thank you. Thanks for the report, patch applied to git. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6947) ldapadd crashes with LDIFs with invalid line termination
by hyc＠symas.com 03 Jun '11

03 Jun '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20110519-ldif-countlines.patch > Submission from: (NULL) (209.132.186.34) > > > Hello, > > adding entries to LDAP database from file using ldapadd tool causes memory > corruption error, when the last line of the input file is not terminated by '\n' > character. Don't do that. The LDIF specification says that all LDIF elements are terminated by SEP (CR LF or LF). Anything not conforming to this is not valid LDIF. As usual, garbage-in-garbage-out. The entries are added correctly. > > All version since 2.4.23 are affected. > > $ cat>/tmp/input.ldif<< EOF >> dn: cn=A,dc=my-domain,dc=com >> objectClass: inetOrgPerson >> objectClass: organizationalPerson >> objectClass: person >> objectClass: top >> cn: A >> sn: A >> uid: A >> mail: A(a)example.com >> EOF > $ wc -c /tmp/input.ldif > 166 /tmp/input.ldif > $ truncate -s 165 /tmp/input.ldif > $ hexdump -c /tmp/input.ldif > 0000000 d n : c n = A , d c = m y - d > 0000010 o m a i n , d c = c o m \n o b j > 0000020 e c t C l a s s : i n e t O r > 0000030 g P e r s o n \n o b j e c t C l > 0000040 a s s : o r g a n i z a t i o > 0000050 n a l P e r s o n \n o b j e c t > 0000060 C l a s s : p e r s o n \n o b > 0000070 j e c t C l a s s : t o p \n c > 0000080 n : A \n s n : A \n u i d : > 0000090 A \n m a i l : A @ e x a m p l > 00000a0 e . c o m > 00000a5 > $ ldapadd -H ldap:// -D cn=Manager,dc=my-domain,dc=com -x -w password -f > /tmp/input.ldif > adding new entry "cn=A,dc=my-domain,dc=com" > > *** glibc detected *** ldapadd: free(): invalid pointer: 0x0000000001c435c8 *** > ======= Backtrace: ========= > /lib64/libc.so.6[0x3626e76d63] > ldapadd[0x404505] > /lib64/libc.so.6(__libc_start_main+0xfd)[0x3626e1ee5d] > ldapadd[0x4037e9] > ======= Memory map: ======== > ... > > I am attaching proposed patch, which fixes this issue. The patch uses a GNU-specific function. Since GLIBC is not supported on all of the platforms OpenLDAP supports, the patch is not acceptable as-is. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6831) Proxycache database corruption
by hyc＠symas.com 03 Jun '11

03 Jun '11

ryans(a)aweber.com wrote: > Some more information: once I changed the search base from ou=Users,dc=example,dc=com to dc=example,dc=com to "fix" the > problem for that particular user (after which the original query with the ou=Users,dc=example,dc=com search base began > working again), the following entries popped up in the log: > ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-fixing-br… > > It gets stranger, though. If I start out by using the root entry as the search base (dc=example,dc=com) with a user who > is not yet in the cache, not only will it say it is ANSWERABLE (which it clearly isn't) and then return nothing without > even trying to reach out to the upstream host, but if I then change the search base to ou=Users,dc=example,dc=com, I get > the following error on the CLI (and this is with a successful bind as the directory admin): > > > ldapsearch -x -D cn=admin,dc=example,dc=com -y /etc/ldap.secret -H ldaps://localhost -LLL -b cn=admin,dc=example,dc=com > '(&(|(objectClass=examplecomUtilityUser)(objectClass=examplecomEmployee))(uid=jdoe4))' uid > No such object (32) > Matched DN: dc=example,dc=com > > Debugging logs generated by that query can be found here: > ftp://ftp.openldap.org/incoming/ryan-steele-110221.proxycache-log-attempt-t… I'm not sure I reproduced all the behaviors you were seeing, but I've reproduced at least one of them and fixed it in git. Please pull the latest pcache.c and test, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6959) ldap_dnfree not mentioned anywhere
by hyc＠symas.com 03 Jun '11

03 Jun '11

frank.muzzulini(a)comsoft.aero wrote: > Full_Name: Frank Muzzulini > Version: 2.4.25 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.221.120.78) > > > Hi, > > Reading the documentation of ldap_str2dn I was wondering how to free the > allocated DN. After browsing for a while I loaded the latest tarball to see some > example code and found ldap_dnfree. > > I re-checked and indeed the function is not mentioned anywhere in the docs > ("find doc -type f | xargs grep ldap_dnfree" found nothing). Added to git, thanks for the report. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6958) slapd segmentation fault with TLSCRLCheck all
by Howard Chu 03 Jun '11

03 Jun '11

Can't reproduce this on Linux. Someone with a FreeBSD installation will have to investigate this.

1 0

Re: (ITS#6960) Out of memory erro occurs when running LDAP
by hyc＠symas.com 03 Jun '11

03 Jun '11

ArunPrasathSevugan(a)oracle.com wrote: > Full_Name: Arun Prasath > Version: 3 > OS: Window Xp > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.225.129.57) > > > Hi, > > We have a tool integrated with LDAP to load all the users in Cognos reporting. > There are about 5000+ users and while running LDAPCONFIG we have been getting > out of memory exception issue. > > In the task manage I could see the LDAP is using memory of around 3 GB and > finally errors out. > > Please help us to load the 5000+ users. It doesn't sound like you're using OpenLDAP. We have no LDAPCONFIG to run and we have no "Version 3" of our software. Please try contacting the actual vendor of your LDAP software. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6864) delta-sync - contextCSN not updating on provider
by hyc＠symas.com 03 Jun '11

03 Jun '11

yuribank(a)gmail.com wrote: > Full_Name: Yuri Bank > Version: 2.4.23-24 > OS: Linux Ubuntu 10.10 > URL: http://yuri.easytospell.net/consumer.provider.txt > Submission from: (NULL) (67.180.182.165) > > > This issue exists in both versions 2.4.23 and 2.4.24 > > I've found an interesting problem with delta-sync replication in which the > ContextCSN on my consumers is higher than the contextCSN on my provider. This is > because the Provider does not properly update its contextCSN for its base suffix > (dc=test,dc=com) when changes are made to group membership. Of couse, if it so > happens that the last change in my database was not a group membership change, > then the contextCSNs will be consistent between my consumers and provider. Sounds like this bug was introduced by patches for ITS#6766 or #6329. Both of those patches have been reverted for ITS#6915. This bug should be fixed in the current git HEAD. > > > I use the following command to check the ContextCSN on each consumer: > > Consumer: 1 > root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b > "dc=test,dc=com" contextCSN dn: dc=test,dc=com > dn: dc=test,dc=com > contextCSN: 20110313041653.752098Z#000000#000#000000 > > Consumer: 2 > ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b > "dc=test,dc=com" contextCSN dn: dc=test,dc=com > dn: dc=test,dc=com > contextCSN: 20110313041653.752098Z#000000#000#000000 > > So we can see that the two consumers have matching contextCSNs: > ContextCSN. 20110313041653.752098Z#000000#000#000000 > > Lets check the Provider now. > > Provider: > root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b > "dc=test,dc=com" ContextCSN dn: dc=test,dc=com > dn: dc=test,dc=com > contextCSN: 20110313041653.709140Z#000000#000#000000 > > The providers CSN is smaller!? > > Lets take a closer look and search cn=accesslog > > These are the last two entries: ( first the user was added, and then the user > was added to a group) > > # 20110313041653.000003Z, accesslog > dn: reqStart=20110313041653.000003Z,cn=accesslog > objectClass: auditAdd > reqStart: 20110313041653.000003Z > reqEnd: 20110313041653.000004Z > reqType: add > reqSession: 34633 > reqAuthzID: cn=admin,dc=test,dc=com > reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com > reqResult: 0 > reqMod: sn:+ Bank > reqMod: userPassword:+ {SASL}banky > reqMod: uid:+ banky > reqMod: objectClass:+ top > reqMod: objectClass:+ person > reqMod: objectClass:+ shadowAccount > reqMod: structuralObjectClass:+ person > reqMod: cn:+ Bank, Yuri(banky) > reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5 > reqMod: creatorsName:+ cn=admin,dc=test,dc=com > reqMod: createTimestamp:+ 20110313041653Z > reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000 > reqMod: modifiersName:+ cn=admin,dc=test,dc=com > reqMod: modifyTimestamp:+ 20110313041653Z > > # 20110313041653.000006Z, accesslog > dn: reqStart=20110313041653.000006Z,cn=accesslog > objectClass: auditModify > reqStart: 20110313041653.000006Z > reqEnd: 20110313041653.000007Z > reqType: modify > reqSession: 34633 > reqAuthzID: cn=admin,dc=test,dc=com > reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com > reqResult: 0 > reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com > reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000 > reqMod: modifiersName:= cn=admin,dc=test,dc=com > reqMod: modifyTimestamp:= 20110313041653Z > > You can see that the consumers have the latest entryCSN (20110313041653.752098Z) > as their contextCSN, but the provider has the entryCSN (20110313041653.709140Z) > before that as its contextCSN: > > If I search the contextCSN on -s base -b cn=accesslog it yields correctly, the > same result as the consumers: > 20110313041653.752098Z#000000#000#000000 > > > As you can see, the provider is not using the latest entryCSN as its ContextCSN, > where as the consumer nodes are. Also notice that the last modification was to > group membership. This problem only seems to exist when Adding/Removing users > from a group. > > A side effect of this issue causes brand new consumers to get stuck in an > infinite loop while syncing for the first time. > > A work around is to make a random change to a User/Person, such as injecting a > random number into their description field AFTER making a change to a group > membership. Such a change will: A. cause the Provider to correctly update its > contextCSN, B. provider and all consumer[s] will have the same contextCSN C. > brand new consumers can be added without getting stuck in an infinite loop when > syncing the database. ( they seem to get stuck on the last entry which makes > sense if the last entry has a higher entryCSN than that of the Providers > contextCSN? ) > > Confgiuration: ( See URL ) > http://yuri.easytospell.net/consumer.provider.txt > > Overlays: > syncprov > accesslog > memberof > > > Please feel free to email me about reproducing this problem. I have a lab with > various configurations and would be happy to give access to anyone interested. > > - Yuri Bank > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6962) Download down?
by h.b.furuseth＠usit.uio.no 03 Jun '11

03 Jun '11

demian.djrn(a)gmail.com writes: > all mirrors are down, i can't download the program. The mirror list needs to be updated. These are down or obsolete: Costa Rica: No /openldap directory. Italy: Unknown host it.openldap.org. Korea: No route to host ftp.holywar.net; TTL exceeded. Portugal: Last update was in 2008. The others work for me. -- Hallvard

1 0

Re: (ITS#6883) Improved Makefiles for contrib modules
by bgmilne＠staff.telkomsa.net 03 Jun '11

03 Jun '11

--Boundary-00=_50J6N9eQwpy3uQe Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit On Tuesday, 29 March 2011 21:20:53 quanah(a)zimbra.com wrote: > --On Tuesday, March 29, 2011 3:25 PM +0000 bgmilne(a)staff.telkomsa.net wrote: > > Full_Name: Buchan Milne > > Version: 2.4.25 > > OS: Linux > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (196.25.124.16) > > > > > > While the code in contrib is not supported, some overlays provide make > > files, some don't, and there were variations in a lot of the make files > > (e.g. use of DESTDIR or not). > > > > In order to add make files for overlays that don't have them, improve the > > consistency of the make files between overlays that had them, and to > > provide some basic sanity testing in a 'test' target, I have created the > > patch at: > > http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/openldap/curre > > nt/SOURCES/openldap-2.4.25-contrib-makefiles-with-tests.patch?revision=64 > > 8744&view=markup > > > > The patch is against 2.4.25, but should apply to master (except that > > there two additional overlays are present in master). Where feasible I > > have retained the majority of an existing make file, in other cases, > > where modifications would exceed the original content, I have replaced > > existing make files wholesale. > > > > The attached patch file is derived from OpenLDAP Software. All of the > > modifications to OpenLDAP Software represented in the following patch(es) > > were developed by Buchan Milne (bgmilne(a)staff.telkomsa.net). I have not > > assigned rights and/or interest in this work to any party. > > Hi Buchan, > > Can you make the patch available via git-format-patch? Please find it attached. Regards, Buchan --Boundary-00=_50J6N9eQwpy3uQe Content-Type: text/x-patch; charset="UTF-8"; name="0001-Fix-contrib-Makefiles-to-use-libtool-and-be-consiste.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0001-Fix-contrib-Makefiles-to-use-libtool-and-be-consiste.patch" =46rom 168ed0544cfd529c8bdff1e5366c1bc60477b1cb Mon Sep 17 00:00:00 2001 =46rom: Buchan Milne <bgmilne(a)staff.telkomsa.net> Date: Fri, 3 Jun 2011 10:18:39 +0200 Subject: [PATCH] Fix contrib Makefiles to use libtool and be consistent (IT= S#6883) This makes existing Makefiles provided with contrib modules more consistent, using libtool for compiling and linking. A trivial test target has also been added, which tests that the module can be loaded. Existing Makefiles were consulted, but were mainly copied from the first working/tested Makefile. As such, any pre-existing copyright notices have been replaced. Makefiles are also provided for all the contrib modules that did not have Makefiles. =2D-- contrib/slapd-modules/acl/Makefile | 48 +++++++++++++++ contrib/slapd-modules/addpartial/Makefile | 50 ++++++++++++++--- contrib/slapd-modules/allop/Makefile | 47 +++++++++++++++ contrib/slapd-modules/allowed/Makefile | 58 ++++++++++--------- contrib/slapd-modules/autogroup/Makefile | 36 +++++++++--- contrib/slapd-modules/cloak/Makefile | 43 ++++++++++++-- contrib/slapd-modules/denyop/Makefile | 48 +++++++++++++++ contrib/slapd-modules/dsaschema/Makefile | 47 +++++++++++++++ contrib/slapd-modules/dupent/Makefile | 58 +++++++++---------- contrib/slapd-modules/kinit/Makefile | 47 +++++++++++++++ contrib/slapd-modules/lastbind/Makefile | 32 +++++++--- contrib/slapd-modules/lastmod/Makefile | 48 +++++++++++++++ contrib/slapd-modules/noopsrch/Makefile | 58 +++++++++---------- contrib/slapd-modules/nops/Makefile | 47 ++++++++++++---- contrib/slapd-modules/nssov/Makefile | 13 ++++- contrib/slapd-modules/passwd/Makefile | 86 +++++++++++++++---------= =2D--- contrib/slapd-modules/passwd/sha2/Makefile | 48 +++++++++++++--- contrib/slapd-modules/trace/Makefile | 48 +++++++++++++++ 18 files changed, 680 insertions(+), 182 deletions(-) create mode 100644 contrib/slapd-modules/acl/Makefile create mode 100644 contrib/slapd-modules/allop/Makefile create mode 100644 contrib/slapd-modules/denyop/Makefile create mode 100644 contrib/slapd-modules/dsaschema/Makefile create mode 100644 contrib/slapd-modules/kinit/Makefile create mode 100644 contrib/slapd-modules/lastmod/Makefile create mode 100644 contrib/slapd-modules/trace/Makefile diff --git a/contrib/slapd-modules/acl/Makefile b/contrib/slapd-modules/acl= /Makefile new file mode 100644 index 0000000..9f48c0d =2D-- /dev/null +++ b/contrib/slapd-modules/acl/Makefile @@ -0,0 +1,48 @@ +# $OpenLDAP$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. + +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +CPPFLAGS+=3D-DSLAPD_OVER_ACL=3DSLAPD_MOD_DYNAMIC +LIBTOOL=3D../../../libtool + +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd + +all: posixgroup.la + +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< + +%.la: %.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< + +clean: + rm -rf *.lo *.la *.o .libs/ + +install: posixgroup.la + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: posixgroup.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/addpartial/Makefile b/contrib/slapd-modu= les/addpartial/Makefile index 3b68815..2f1fd31 100644 =2D-- a/contrib/slapd-modules/addpartial/Makefile +++ b/contrib/slapd-modules/addpartial/Makefile @@ -1,13 +1,47 @@ # $OpenLDAP$ =2DOPENLDAP_SRC=3D../../.. =2DOPENLDAP_BLD=3D../../.. =2DCPPFLAGS+=3D-I${OPENLDAP_SRC}/include -I${OPENLDAP_SRC}/servers/slapd -I= ${OPENLDAP_BLD}/include =2DCC=3Dgcc +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. =20 =2Dall: addpartial-overlay.so +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +LIBTOOL=3D../../../libtool =20 =2Daddpartial-overlay.so: addpartial-overlay.c =2D $(CC) -shared $(CPPFLAGS) $(LDFLAGS) -Wall -o $@ $? +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd + +all: addpartial.la + +%.lo: addpartial-overlay.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< -o addpartial.lo + +%.la: %.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< =20 clean: =2D rm addpartial-overlay.so + rm -rf *.lo *.la *.o .libs/ + +install: addpartial.la + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: addpartial.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/allop/Makefile b/contrib/slapd-modules/a= llop/Makefile new file mode 100644 index 0000000..a995e61 =2D-- /dev/null +++ b/contrib/slapd-modules/allop/Makefile @@ -0,0 +1,47 @@ +# $OpenLDAP$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. + +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +LIBTOOL=3D../../../libtool + +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd + +all: allop.la + +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< + +%.la: %.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< + +clean: + rm -rf *.lo *.la *.o .libs/ + +install: allop.la + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: allop.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/allowed/Makefile b/contrib/slapd-modules= /allowed/Makefile index 8f5be91..75e63c1 100644 =2D-- a/contrib/slapd-modules/allowed/Makefile +++ b/contrib/slapd-modules/allowed/Makefile @@ -1,8 +1,6 @@ =2D# $OpenLDAP$ =2D# This work is part of OpenLDAP Software <http://www.openldap.org/>. =2D# =2D# Copyright 1998-2011 The OpenLDAP Foundation. =2D# Copyright 2004 Howard Chu, Symas Corp. All Rights Reserved. +# $$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted only as authorized by the OpenLDAP @@ -12,35 +10,39 @@ # top-level directory of the distribution or, alternatively, at # <http://www.OpenLDAP.org/license.html>. =20 =2DPREFIX=3D/opt/openldap-HEAD =2D +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +CPPFLAGS+=3D-DSLAPD_OVER_ALLOWED=3DSLAPD_MOD_DYNAMIC LIBTOOL=3D../../../libtool =2DOPT=3D-g -O2 =2DCC=3Dgcc =2D =2DDEFS=3D-DSLAPD_OVER_ALLOWED=3DSLAPD_MOD_DYNAMIC =2D =2DLDAP_INC=3D-I../../../include -I../../../servers/slapd =2DINCS=3D$(LDAP_INC) =2D =2DLDAP_LIB=3D-lldap_r -llber -L../../../lib =2DLDAP_LIB=3D =2DLIBS=3D$(LDAP_LIB) =20 =2Dall: allowed.la +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd =20 +all: allowed.la =20 =2Dallowed.lo: allowed.c =2D $(LIBTOOL) --mode=3Dcompile $(CC) $(OPT) $(DEFS) $(INCS) -c $? +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< =20 =2Dallowed.la: allowed.lo =2D $(LIBTOOL) --mode=3Dlink $(CC) $(OPT) -version-info 0:0:0 \ =2D -rpath $(PREFIX)/lib -module -o $@ $? $(LIBS) +%.la: %.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< =20 clean: =2D rm -f allowed.o allowed.lo allowed.la + rm -rf *.lo *.la *.o .libs/ =20 install: allowed.la =2D mkdir -p $(PREFIX)/libexec/openldap =2D $(LIBTOOL) --mode=3Dinstall cp allowed.la $(PREFIX)/libexec/openldap =2D $(LIBTOOL) --finish $(PREFIX)/libexec/openldap + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: allowed.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/autogroup/Makefile b/contrib/slapd-modul= es/autogroup/Makefile index 70146ac..4438cbf 100644 =2D-- a/contrib/slapd-modules/autogroup/Makefile +++ b/contrib/slapd-modules/autogroup/Makefile @@ -1,6 +1,17 @@ =2DLIBTOOL=3D../../../libtool +# $OpenLDAP$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. =20 =2DCPPFLAGS+=3D-I../../../include -I../../../servers/slapd +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +LIBTOOL=3D../../../libtool =20 ldap_subdir =3D openldap prefix=3D/usr/local @@ -8,20 +19,29 @@ exec_prefix =3D $(prefix) libdir =3D $(exec_prefix)/lib libexecdir =3D $(exec_prefix)/libexec moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd =20 all: autogroup.la =20 =2Dautogroup.lo: autogroup.c =2D $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $? +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< =20 =2Dautogroup.la: autogroup.lo +%.la: %.lo $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ =2D -rpath $(libdir) -module -o $@ $?=20 + -rpath $(moduledir) -module -o $@ $< =20 clean: =2D rm -f autogroup.lo autogroup.la + rm -rf *.lo *.la *.o .libs/ =20 install: autogroup.la mkdir -p $(DESTDIR)$(moduledir) =2D $(LIBTOOL) --mode=3Dinstall cp autogroup.la $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: autogroup.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/cloak/Makefile b/contrib/slapd-modules/c= loak/Makefile index 4562fcb..d92ff8b 100644 =2D-- a/contrib/slapd-modules/cloak/Makefile +++ b/contrib/slapd-modules/cloak/Makefile @@ -1,17 +1,48 @@ # $OpenLDAP$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. + CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 CPPFLAGS+=3D-DSLAPD_OVER_CLOAK=3DSLAPD_MOD_DYNAMIC =2DLIBS=3D-lldap_r -llber -lcrypto LIBTOOL=3D../../../libtool =20 +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd + all: cloak.la =20 =2Dcloak.lo: cloak.c =2D $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -c $? +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< =20 =2Dcloak.la: cloak.lo +%.la: %.lo $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ =2D -rpath $(PREFIX)/lib -module -o $@ $? $(LIBS) + -rpath $(moduledir) -module -o $@ $< =20 clean: =2D rm cloak.lo cloak.la + rm -rf *.lo *.la *.o .libs/ + +install: cloak.la + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: cloak.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/denyop/Makefile b/contrib/slapd-modules/= denyop/Makefile new file mode 100644 index 0000000..711eee7 =2D-- /dev/null +++ b/contrib/slapd-modules/denyop/Makefile @@ -0,0 +1,48 @@ +# $OpenLDAP$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. + +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +CPPFLAGS+=3D-DSLAPD_OVER_DENYOP=3DSLAPD_MOD_DYNAMIC +LIBTOOL=3D../../../libtool + +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd + +all: denyop.la + +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< + +%.la: %.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< + +clean: + rm -rf *.lo *.la *.o .libs/ + +install: denyop.la + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: denyop.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/dsaschema/Makefile b/contrib/slapd-modul= es/dsaschema/Makefile new file mode 100644 index 0000000..90f711e =2D-- /dev/null +++ b/contrib/slapd-modules/dsaschema/Makefile @@ -0,0 +1,47 @@ +# $OpenLDAP$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. + +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +LIBTOOL=3D../../../libtool + +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd + +all: dsaschema.la + +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< + +%.la: %.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< + +clean: + rm -rf *.lo *.la *.o .libs/ + +install: dsaschema.la + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: dsaschema.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/dupent/Makefile b/contrib/slapd-modules/= dupent/Makefile index 54a69ce..c1e8997 100644 =2D-- a/contrib/slapd-modules/dupent/Makefile +++ b/contrib/slapd-modules/dupent/Makefile @@ -1,8 +1,6 @@ # $OpenLDAP$ =2D# This work is part of OpenLDAP Software <http://www.openldap.org/>. =2D# =2D# Copyright 1998-2011 The OpenLDAP Foundation. =2D# Copyright 2004 Howard Chu, Symas Corp. All Rights Reserved. +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted only as authorized by the OpenLDAP @@ -12,41 +10,39 @@ # top-level directory of the distribution or, alternatively, at # <http://www.OpenLDAP.org/license.html>. =20 +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +CPPFLAGS+=3D-DSLAPD_OVER_DUPENT=3DSLAPD_MOD_DYNAMIC -g -O2 LIBTOOL=3D../../../libtool =2DOPT=3D-DSLAPD_OVER_DUPENT=3D2 -g -O2 =2D#LIBTOOL=3D../../../../ldap-devel/libtool =2D#OPT=3D-DSLAPD_OVER_DUPENT=3D2 -g -O0 =2DCC=3Dgcc =2D =2DLDAP_INC=3D-I../../../include -I../../../servers/slapd =2D#LDAP_INC=3D-I../../../include -I../../../servers/slapd -I../../../../ld= ap-devel/include =2DINCS=3D$(LDAP_INC) =2D =2DLDAP_LIB=3D-lldap_r -llber =2DLIBS=3D$(LDAP_LIB) =20 +ldap_subdir =3D openldap prefix=3D/usr/local =2Dexec_prefix=3D$(prefix) =2Dldap_subdir=3D/openldap +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd =20 =2Dlibdir=3D$(exec_prefix)/lib =2Dlibexecdir=3D$(exec_prefix)/libexec =2Dmoduledir =3D $(libexecdir)$(ldap_subdir) +all: dupent.la =20 =2Dall: dupent.la +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< =20 =2D =2Ddupent.lo: dupent.c =2D $(LIBTOOL) --mode=3Dcompile $(CC) $(OPT) $(DEFS) $(INCS) -c $? =2D =2Ddupent.la: dupent.lo =2D $(LIBTOOL) --mode=3Dlink $(CC) $(OPT) -version-info 0:0:0 \ =2D -rpath $(moduledir) -module -o $@ $? $(LIBS) +%.la: %.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< =20 clean: =2D rm -f dupent.lo dupent.la + rm -rf *.lo *.la *.o .libs/ =20 install: dupent.la mkdir -p $(DESTDIR)$(moduledir) =2D $(LIBTOOL) --mode=3Dinstall cp dupent.la $(DESTDIR)$(moduledir) =2D + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: dupent.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/kinit/Makefile b/contrib/slapd-modules/k= init/Makefile new file mode 100644 index 0000000..750c7b9 =2D-- /dev/null +++ b/contrib/slapd-modules/kinit/Makefile @@ -0,0 +1,47 @@ +# $OpenLDAP$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. + +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +LIBTOOL=3D../../../libtool + +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd + +all: kinit.la + +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< + +%.la: %.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< -lkrb5 + +clean: + rm -rf *.lo *.la *.o .libs/ + +install: kinit.la + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: kinit.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/lastbind/Makefile b/contrib/slapd-module= s/lastbind/Makefile index ecc9ed1..643b0c1 100644 =2D-- a/contrib/slapd-modules/lastbind/Makefile +++ b/contrib/slapd-modules/lastbind/Makefile @@ -1,5 +1,5 @@ # $OpenLDAP$ =2D# Copyright 2009 Jonathan Clarke <jonathan(a)phillipoux.net>. +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> # All rights reserved. # # Redistribution and use in source and binary forms, with or without @@ -12,23 +12,37 @@ =20 CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 CPPFLAGS+=3D-DSLAPD_OVER_LASTBIND=3DSLAPD_MOD_DYNAMIC =2D#LIBTOOL=3Dlibtool LIBTOOL=3D../../../libtool =20 +ldap_subdir =3D openldap prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd =20 all: lastbind.la =20 =2Dlastbind.lo: lastbind.c =2D $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $? +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< =20 =2Dlastbind.la: lastbind.lo +%.la: %.lo $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ =2D -rpath $(prefix)/lib -module -o $@ $? + -rpath $(moduledir) -module -o $@ $< =20 clean: =2D rm -rf lastbind.lo lastbind.la lastbind.o .libs/ + rm -rf *.lo *.la *.o .libs/ =20 install: lastbind.la =2D mkdir -p $(prefix)/libexec/openldap =2D $(LIBTOOL) --mode=3Dinstall cp lastbind.la $(prefix)/libexec/openldap + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: lastbind.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/lastmod/Makefile b/contrib/slapd-modules= /lastmod/Makefile new file mode 100644 index 0000000..e9f0408 =2D-- /dev/null +++ b/contrib/slapd-modules/lastmod/Makefile @@ -0,0 +1,48 @@ +# $OpenLDAP$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. + +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +CPPFLAGS+=3D-DSLAPD_OVER_LASTMOD=3DSLAPD_MOD_DYNAMIC +LIBTOOL=3D../../../libtool + +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd + +all: lastmod.la + +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< + +%.la: %.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< + +clean: + rm -rf *.lo *.la *.o .libs/ + +install: lastmod.la + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: lastmod.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/noopsrch/Makefile b/contrib/slapd-module= s/noopsrch/Makefile index d90bc59..7227582 100644 =2D-- a/contrib/slapd-modules/noopsrch/Makefile +++ b/contrib/slapd-modules/noopsrch/Makefile @@ -1,8 +1,6 @@ # $OpenLDAP$ =2D# This work is part of OpenLDAP Software <http://www.openldap.org/>. =2D# =2D# Copyright 1998-2011 The OpenLDAP Foundation. =2D# Copyright 2004 Howard Chu, Symas Corp. All Rights Reserved. +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted only as authorized by the OpenLDAP @@ -12,41 +10,39 @@ # top-level directory of the distribution or, alternatively, at # <http://www.OpenLDAP.org/license.html>. =20 +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +CPPFLAGS+=3D-DSLAPD_OVER_NOOPSRCH=3DSLAPD_MOD_DYNAMIC -g -O2 LIBTOOL=3D../../../libtool =2DOPT=3D-DSLAPD_OVER_NOOPSRCH=3D2 -g -O2 =2D#LIBTOOL=3D../../../../ldap-devel/libtool =2D#OPT=3D-DSLAPD_OVER_NOOPSRCH=3D2 -g -O0 =2DCC=3Dgcc =2D =2DLDAP_INC=3D-I../../../include -I../../../servers/slapd =2D#LDAP_INC=3D-I../../../include -I../../../servers/slapd -I../../../../ld= ap-devel/include =2DINCS=3D$(LDAP_INC) =2D =2DLDAP_LIB=3D-lldap_r -llber =2DLIBS=3D$(LDAP_LIB) =20 +ldap_subdir =3D openldap prefix=3D/usr/local =2Dexec_prefix=3D$(prefix) =2Dldap_subdir=3D/openldap +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd =20 =2Dlibdir=3D$(exec_prefix)/lib =2Dlibexecdir=3D$(exec_prefix)/libexec =2Dmoduledir =3D $(libexecdir)$(ldap_subdir) +all: noopsrch.la =20 =2Dall: noopsrch.la +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< =20 =2D =2Dnoopsrch.lo: noopsrch.c =2D $(LIBTOOL) --mode=3Dcompile $(CC) $(OPT) $(DEFS) $(INCS) -c $? =2D =2Dnoopsrch.la: noopsrch.lo =2D $(LIBTOOL) --mode=3Dlink $(CC) $(OPT) -version-info 0:0:0 \ =2D -rpath $(moduledir) -module -o $@ $? $(LIBS) +%.la: %.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< =20 clean: =2D rm -f noopsrch.lo noopsrch.la + rm -rf *.lo *.la *.o .libs/ =20 install: noopsrch.la mkdir -p $(DESTDIR)$(moduledir) =2D $(LIBTOOL) --mode=3Dinstall cp noopsrch.la $(DESTDIR)$(moduledir) =2D + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: noopsrch.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/nops/Makefile b/contrib/slapd-modules/no= ps/Makefile index fce44e0..6da5cd0 100644 =2D-- a/contrib/slapd-modules/nops/Makefile +++ b/contrib/slapd-modules/nops/Makefile @@ -1,23 +1,48 @@ # $OpenLDAP$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. + CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 CPPFLAGS+=3D-DSLAPD_OVER_NOPS=3DSLAPD_MOD_DYNAMIC =2DLIBS=3D-L$(PREFIX)/lib -lldap_r -llber -lcrypto +LIBTOOL=3D../../../libtool + +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd =20 all: nops.la =20 =2Dnops.lo: nops.c =2D $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -c $? +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< =20 =2Dnops.la: nops.lo +%.la: %.lo $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ =2D -rpath $(PREFIX)/lib -module -o $@ $? $(LIBS) + -rpath $(moduledir) -module -o $@ $< =20 clean: =2D rm -f nops.lo nops.la + rm -rf *.lo *.la *.o .libs/ =20 install: nops.la =2D mkdir -p $(PREFIX)/lib/openldap=20 =2D mkdir -p $(PREFIX)/man/man5 =2D $(LIBTOOL) --mode=3Dinstall cp nops.la $(PREFIX)/lib/openldap =2D $(LIBTOOL) --finish $(PREFIX)/lib =2D cp nops.5 $(PREFIX)/man/man5 + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: nops.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/nssov/Makefile b/contrib/slapd-modules/n= ssov/Makefile index 322fcdd..f1ec793 100644 =2D-- a/contrib/slapd-modules/nssov/Makefile +++ b/contrib/slapd-modules/nssov/Makefile @@ -28,7 +28,7 @@ NLDAPD_INC=3D-Inss-pam-ldapd INCS=3D$(LDAP_INC) $(NLDAPD_INC) =20 LDAP_LIB=3D-lldap_r -llber =2DLIBS=3D$(LDAP_LIB) +LIBS=3D-L../../../libraries/liblber -L../../../libraries/libldap_r $(LDAP_= LIB) =20 prefix=3D/usr/local exec_prefix=3D$(prefix) @@ -39,6 +39,7 @@ libexecdir=3D$(exec_prefix)/libexec moduledir =3D $(libexecdir)$(ldap_subdir) sysconfdir =3D $(prefix)/etc$(ldap_subdir) schemadir =3D $(sysconfdir)/schema +slapd=3D../../../servers/slapd/slapd =20 all: nssov.la =20 @@ -59,7 +60,7 @@ $(OBJS): nssov.h =20 nssov.la: $(OBJS) $(XOBJS) $(LIBTOOL) --mode=3Dlink $(CC) $(OPT) -version-info 0:0:0 \ =2D -rpath $(libdir) -module -o $@ $(OBJS) $(XOBJS) $(LIBS) + -rpath $(moduledir) -module -o $@ $(OBJS) $(XOBJS) $(LIBS) =20 install: nssov.la mkdir -p $(DESTDIR)$(moduledir) @@ -69,3 +70,11 @@ install: nssov.la clean: rm -f *.*o *.la .libs/* rm -rf .libs + +test: nssov.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/passwd/Makefile b/contrib/slapd-modules/= passwd/Makefile index 1e49e6a..748b4ce 100644 =2D-- a/contrib/slapd-modules/passwd/Makefile +++ b/contrib/slapd-modules/passwd/Makefile @@ -1,46 +1,52 @@ # $OpenLDAP$ =2DCPPFLAGS+=3D-I../../../include -I../../../servers/slapd =2D =2Dall: kerberos.la netscape.la radius.la apr1.la =2D =2Dkerberos.lo: kerberos.c =2D $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -DHAVE_KRB5 -Wall -c $? =2D =2Dkerberos.la: kerberos.lo =2D $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ =2D -rpath $(PREFIX)/lib -module -o $@ $? -lkrb5 =2D =2Dnetscape.lo: netscape.c =2D $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $? =2D =2Dnetscape.la: netscape.lo +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. + +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +LIBTOOL=3D../../../libtool +SUBDIRS =3D sha2 + +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd + +all: kerberos.la netscape.la radius.la + +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< + +kerberos.la: kerberos.lo $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ =2D -rpath $(PREFIX)/lib -module -o $@ $?=20 =2D =2Dradius.lo: radius.c =2D $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $? =2D =2Dradius.la: radius.lo =2D $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ =2D -rpath $(PREFIX)/lib -module -o $@ $? -lradius =2D =2Dapr1.lo: apr1.c =2D $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $? + -rpath $(moduledir) -module -o $@ $< -lkrb5 =20 =2Dapr1.la: apr1.lo +%.la: %.lo $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ =2D -rpath $(PREFIX)/lib -module -o $@ $?=20 + -rpath $(moduledir) -module -o $@ $< =20 clean: =2D rm -f kerberos.lo kerberos.la =2D rm -f netscape.lo netscape.la =2D rm -f radius.lo radius.la =2D rm -f apr1.lo apr1.la =2D =2Dinstall: kerberos.la netscape.la radius.la apr1.la =2D mkdir -p $(PREFIX)/lib/openldap =2D $(LIBTOOL) --mode=3Dinstall cp kerberos.la $(PREFIX)/lib/openldap =2D $(LIBTOOL) --mode=3Dinstall cp netscape.la $(PREFIX)/lib/openldap =2D $(LIBTOOL) --mode=3Dinstall cp radius.la $(PREFIX)/lib/openldap =2D $(LIBTOOL) --mode=3Dinstall cp apr1.la $(PREFIX)/lib/openldap =2D $(LIBTOOL) --finish $(PREFIX)/lib + rm -rf *.lo *.la *.o .libs/ + +install: kerberos.la netscape.la radius.la + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: kerberos.la netscape.la radius.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/passwd/sha2/Makefile b/contrib/slapd-mod= ules/passwd/sha2/Makefile index 5dcb1db..d03297d 100644 =2D-- a/contrib/slapd-modules/passwd/sha2/Makefile +++ b/contrib/slapd-modules/passwd/sha2/Makefile @@ -1,15 +1,47 @@ # $OpenLDAP$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. =20 =2DOPENLDAP :=3D ../../../.. +CPPFLAGS+=3D-I../../../../include -I../../../../servers/slapd=20 +LIBTOOL=3D../../../../libtool =20 =2D#CCFLAGS =3D -Wall -g -DSLAPD_SHA2_DEBUG =2DCCFLAGS =3D -Wall -g +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../../servers/slapd/slapd =20 =2Dslapd-sha2.so: slapd-sha2.o sha2.o =2D $(CC) -I$(OPENLDAP)/include -shared -Wall -g $^ -o $@ +all: sha2.la =20 =2D%.o: %.c =2D $(CC) -I$(OPENLDAP)/include $(CCFLAGS) -c $< +%.lo: slapd-sha2.c sha2.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< + +%.la: slapd-sha2.lo sha2.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< =20 clean: =2D @rm -f slapd-sha2.so *.o + rm -rf *.lo *.la *.o .libs/ + +install: sha2.la + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: sha2.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done diff --git a/contrib/slapd-modules/trace/Makefile b/contrib/slapd-modules/t= race/Makefile new file mode 100644 index 0000000..948ffef =2D-- /dev/null +++ b/contrib/slapd-modules/trace/Makefile @@ -0,0 +1,48 @@ +# $OpenLDAP$ +# Copyright 2011 Buchan Milne <bgmilne(a)staff.telkomsa.net> +# All rights reserved. +# +# Redistribution and use in source and binary forms, with or without +# modification, are permitted only as authorized by the OpenLDAP +# Public License. +# +# A copy of this license is available in the file LICENSE in the +# top-level directory of the distribution or, alternatively, at +# <http://www.OpenLDAP.org/license.html>. + +CPPFLAGS+=3D-I../../../include -I../../../servers/slapd=20 +CPPFLAGS+=3D-DSLAPD_OVER_TRACE=3DSLAPD_MOD_DYNAMIC +LIBTOOL=3D../../../libtool + +ldap_subdir =3D openldap +prefix=3D/usr/local +exec_prefix =3D $(prefix) +libdir =3D $(exec_prefix)/lib +libexecdir =3D $(exec_prefix)/libexec +moduledir =3D $(exec_prefix)/libexec/$(ldap_subdir) +slapd=3D../../../servers/slapd/slapd + +all: trace.la + +%.lo: %.c + $(LIBTOOL) --mode=3Dcompile $(CC) $(CPPFLAGS) -Wall -c $< + +%.la: %.lo + $(LIBTOOL) --mode=3Dlink $(CC) -version-info 0:0:0 \ + -rpath $(moduledir) -module -o $@ $< + +clean: + rm -rf *.lo *.la *.o .libs/ + +install: trace.la + mkdir -p $(DESTDIR)$(moduledir) + $(LIBTOOL) --mode=3Dinstall cp $? $(DESTDIR)$(moduledir) + $(LIBTOOL) --finish $(DESTDIR)$(moduledir) + +test: trace.la + @for i in $?;do \ + echo "Testing loading module $$i"; \ + echo "modulepath ." > test-slapd.conf; \ + echo "moduleload $$i" >> test-slapd.conf; \ + $(slapd) -T test -f test-slapd.conf && rm -f test-slapd.conf; \ + done =2D-=20 1.7.1 --Boundary-00=_50J6N9eQwpy3uQe--

1 0

(ITS#6962) Download down?
by demian.djrn＠gmail.com 02 Jun '11

02 Jun '11

Full_Name: Demian J Ramirez Version: ----- OS: windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (189.178.46.195) all mirrors are down, i can't download the program.

1 0

Re: (ITS#6915) memberof+accesslog duplicate reqStart
by subbarao＠computer.org 01 Jun '11

01 Jun '11

On 06/01/2011 07:36 PM, Yuri Bank wrote: > Do you think this could be related to: > http://www.openldap.org/its/index.cgi?findid=6864 > > I've been having similar issues with MemberOf and Accesslog overlays > used together. I've occasionally experienced similar things that you describe but haven't captured the detailed data to be able to correlate that with this issue. > In your fix, is the memberof overlay enabled on your consumer nodes? No, it is disabled everywhere. -Kartik

1 0

Re: (ITS#6915) memberof+accesslog duplicate reqStart
by yuribank＠gmail.com 01 Jun '11

01 Jun '11

--bcaec520e733d305e204a4aefc06 Content-Type: text/plain; charset=ISO-8859-1 Do you think this could be related to: http://www.openldap.org/its/index.cgi?findid=6864 I've been having similar issues with MemberOf and Accesslog overlays used together. In your fix, is the memberof overlay enabled on your consumer nodes? -Yuri On Wed, Jun 1, 2011 at 1:00 PM, <subbarao(a)computer.org> wrote: > This is a multi-part message in MIME format. > --------------050703040907090602090901 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > I figured I would share a workaround that I'm currently using for this > issue which may be of help to others. I've disabled the memberOf overlay > in slapd, and use an external script to populate memberOf on the master > server, which then replicates to the consumer servers. I currently run > this every 5 minutes from cron as follows: > > memberof.pl --ldap > > Regards, > > -Kartik > > --------------050703040907090602090901 > Content-Type: application/x-perl; > name="memberof.pl" > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename="memberof.pl" > > #! /usr/bin/perl > > # Implements memberOf reverse mapping attributes -- workaround for when > # memberOf overlay isn't available > > use Net::LDAP; > use Net::LDAP::LDIF; > use Authen::SASL; > use Fcntl qw(LOCK_EX LOCK_NB); > use Getopt::Long; > > use strict; > > my $basedn = "dc=example,dc=com"; > > my @attrs = qw(member manager); > # Note -- this filter properly excludes dynamic groupOfURLs groups > my $attrfilter = '(|' . join("", map { "($_=*)" } @attrs) . ')'; > my %revattrs = (member => 'memberOf', manager => 'directReports'); > my %fwattrs = reverse %revattrs; > my $revattrfilter = '(|' . join("", map { "($_=*)" } values %revattrs) . > ')'; > my (%entries, %reventries); > > # Prevent multiple instances from running at the same time > open(LOCKFH, $0); flock(LOCKFH, LOCK_EX|LOCK_NB) or exit 1; > > my ($generate_ldif, $update_ldap); > GetOptions('ldif' => \$generate_ldif, 'ldap' => \$update_ldap); > > my $ldifout = Net::LDAP::LDIF->new('-', 'w'); > $ldifout->{change} = 1; > my $ldap = Net::LDAP->new('ldapi://') or die "ldapi: $@\n"; > my $sasl = Authen::SASL->new(mechanism => 'EXTERNAL'); > my $sasl_client = $sasl->client_new('ldap', 'localhost'); > $ldap->bind(undef, sasl => $sasl_client); > > # Build %entries and %reventries maps > my $mesg = $ldap->search(base => $basedn, > filter => $attrfilter, > attrs => \@attrs); > $mesg->code && die($mesg->error . "\n"); > foreach my $entry ($mesg->all_entries) {$entries{lc $entry->dn} = $entry } > > $mesg = $ldap->search(base => $basedn, > filter => $revattrfilter, > attrs => [values > %revattrs]); > $mesg->code && die($mesg->error . "\n"); > foreach my $entry ($mesg->all_entries) { $reventries{lc $entry->dn} = > $entry } > > # Go through and generate updates for the reverse mapping attributes > my ($dn, $entry); > while (($dn, $entry) = each %entries) { > foreach my $attr (@attrs) { > my $revattr = $revattrs{$attr}; > foreach my $val ($entry->get_value($attr)) { > $val = lc $val; > if (!$reventries{$val}) { > $reventries{$val} = Net::LDAP::Entry->new; > $reventries{$val}->dn($val); > $reventries{$val}->changetype('modify'); > } > $reventries{$val}->add($revattr => $entry->dn) > unless grep({ lc $_ eq $dn } > > $reventries{$val}->get_value($revattr)); > } > } > } > while (($dn, $entry) = each %reventries) { > foreach my $revattr (values %revattrs) { > foreach my $val ($entry->get_value($revattr)) { > $val = lc $val; > $reventries{$dn}->delete($revattr => $val) > if !exists($entries{$val}) > || !grep({ lc $_ eq $dn } > > $entries{$val}->get_value($fwattrs{$revattr})); > > } > } > if ($entry->changes) { > $ldifout->write_entry($entry) if $generate_ldif; > if ($update_ldap) { > my $modmesg = $entry->update($ldap); > $modmesg->code && die("LDAP: " .$modmesg->error . > "\n"); > } > } > } > > --------------050703040907090602090901-- > > > --bcaec520e733d305e204a4aefc06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Do you think this could be related to: <a href=3D"http://www.openldap.org/i= ts/index.cgi?findid=3D6864">http://www.openldap.org/its/index.cgi?findid=3D= 6864</a>=A0 I've been having similar issues with MemberOf and A= ccesslog overlays used together. In your fix, is the memberof overlay enabled on your consumer nodes= ? -Yuri <div class=3D"gmail_quote">On Wed, Jun 1, 2011 at 1:0= 0 PM, <<a href=3D"mailto:subbarao@computer.org">subba= rao(a)computer.org</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">This is a multi-part message in MIME format= . --------------050703040907090602090901 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit I figured I would share a workaround that I'm currently using for this<= br> issue which may be of help to others. I've disabled the memberOf overla= y in slapd, and use an external script to populate memberOf on the master server, which then replicates to the consumer servers. I currently run this every 5 minutes from cron as follows: <a href=3D"http://memberof.pl" target=3D"_blank">memberof.pl</a> --ldap Regards, =A0 =A0 =A0 =A0-Kartik --------------050703040907090602090901 Content-Type: application/x-perl; =A0name=3D"<a href=3D"http://memberof.pl" target=3D"_blank">memberof.p= l</a>" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; =A0filename=3D"<a href=3D"http://memberof.pl" target=3D"_blank">member= of.pl</a>" #! /usr/bin/perl # Implements memberOf reverse mapping attributes -- workaround for when # memberOf overlay isn't available use Net::LDAP; use Net::LDAP::LDIF; use Authen::SASL; use Fcntl qw(LOCK_EX LOCK_NB); use Getopt::Long; use strict; my $basedn =3D "dc=3Dexample,dc=3Dcom"; my @attrs =3D qw(member manager); # Note -- this filter properly excludes dynamic groupOfURLs groups my $attrfilter =3D '(|' . join("", map { "($_=3D*)&q= uot; } @attrs) . ')'; my %revattrs =3D (member =3D> 'memberOf', manager =3D> 'd= irectReports'); my %fwattrs =3D reverse %revattrs; my $revattrfilter =3D '(|' . join("", map { "($_=3D*= )" } values %revattrs) . ')'; my (%entries, %reventries); # Prevent multiple instances from running at the same time open(LOCKFH, $0); flock(LOCKFH, LOCK_EX|LOCK_NB) or exit 1; my ($generate_ldif, $update_ldap); GetOptions('ldif' =3D> \$generate_ldif, 'ldap' =3D> \= $update_ldap); my $ldifout =3D Net::LDAP::LDIF->new('-', 'w'); $ldifout->{change} =3D 1; my $ldap =3D Net::LDAP->new('ldapi://') or die "ldapi: $@\n= "; my $sasl =3D Authen::SASL->new(mechanism =3D> 'EXTERNAL');<br= > my $sasl_client =3D $sasl->client_new('ldap', 'localhost&#39= ;); $ldap->bind(undef, sasl =3D> $sasl_client); # Build %entries and %reventries maps my $mesg =3D $ldap->search(base =3D> $basedn, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 filter =3D> $attrfilter, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 attrs =3D> \@attrs); $mesg->code && die($mesg->error . "\n"); foreach my $entry ($mesg->all_entries) {$entries{lc $entry->dn} =3D $= entry } $mesg =3D $ldap->search(base =3D> $basedn, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 filter =3D> $revattrfilter, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 attrs =3D> [values %revattrs]); $mesg->code && die($mesg->error . "\n"); foreach my $entry ($mesg->all_entries) { $reventries{lc $entry->dn} = =3D $entry } # Go through and generate updates for the reverse mapping attributes my ($dn, $entry); while (($dn, $entry) =3D each %entries) { =A0 =A0 =A0 =A0foreach my $attr (@attrs) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my $revattr =3D $revattrs{$attr}; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0foreach my $val ($entry->get_value($attr= )) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$val =3D lc $val; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!$reventries{$val}) {<b= r> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries= {$val} =3D Net::LDAP::Entry->new; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries= {$val}->dn($val); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries= {$val}->changetype('modify'); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries{$val}->add($= revattr =3D> $entry->dn) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0unless grep= ({ lc $_ eq $dn } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries{$val}->get_value($rev= attr)); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0} } while (($dn, $entry) =3D each %reventries) { =A0 =A0 =A0 =A0foreach my $revattr (values %revattrs) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0foreach my $val ($entry->get_value($reva= ttr)) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$val =3D lc $val; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$reventries{$dn}->delete= ($revattr =3D> $val) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if !exists(= $entries{$val}) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|| !grep({ = lc $_ eq $dn } =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 $entries{$val}->get_value($fwattrs{$revattr}));<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0if ($entry->changes) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$ldifout->write_entry($entry) if $genera= te_ldif; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ($update_ldap) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my $modmesg =3D $entry->= update($ldap); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$modmesg->code &&amp= ; die("LDAP: " .$modmesg->error . =A0"\n"); =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} =A0 =A0 =A0 =A0} } --------------050703040907090602090901-- </blockquote></div> --bcaec520e733d305e204a4aefc06--

1 0

Re: (ITS#6915) memberof+accesslog duplicate reqStart
by subbarao＠computer.org 01 Jun '11

01 Jun '11

This is a multi-part message in MIME format. --------------050703040907090602090901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I figured I would share a workaround that I'm currently using for this issue which may be of help to others. I've disabled the memberOf overlay in slapd, and use an external script to populate memberOf on the master server, which then replicates to the consumer servers. I currently run this every 5 minutes from cron as follows: memberof.pl --ldap Regards, -Kartik --------------050703040907090602090901 Content-Type: application/x-perl; name="memberof.pl" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="memberof.pl" #! /usr/bin/perl # Implements memberOf reverse mapping attributes -- workaround for when # memberOf overlay isn't available use Net::LDAP; use Net::LDAP::LDIF; use Authen::SASL; use Fcntl qw(LOCK_EX LOCK_NB); use Getopt::Long; use strict; my $basedn = "dc=example,dc=com"; my @attrs = qw(member manager); # Note -- this filter properly excludes dynamic groupOfURLs groups my $attrfilter = '(|' . join("", map { "($_=*)" } @attrs) . ')'; my %revattrs = (member => 'memberOf', manager => 'directReports'); my %fwattrs = reverse %revattrs; my $revattrfilter = '(|' . join("", map { "($_=*)" } values %revattrs) . ')'; my (%entries, %reventries); # Prevent multiple instances from running at the same time open(LOCKFH, $0); flock(LOCKFH, LOCK_EX|LOCK_NB) or exit 1; my ($generate_ldif, $update_ldap); GetOptions('ldif' => \$generate_ldif, 'ldap' => \$update_ldap); my $ldifout = Net::LDAP::LDIF->new('-', 'w'); $ldifout->{change} = 1; my $ldap = Net::LDAP->new('ldapi://') or die "ldapi: $@\n"; my $sasl = Authen::SASL->new(mechanism => 'EXTERNAL'); my $sasl_client = $sasl->client_new('ldap', 'localhost'); $ldap->bind(undef, sasl => $sasl_client); # Build %entries and %reventries maps my $mesg = $ldap->search(base => $basedn, filter => $attrfilter, attrs => \@attrs); $mesg->code && die($mesg->error . "\n"); foreach my $entry ($mesg->all_entries) {$entries{lc $entry->dn} = $entry } $mesg = $ldap->search(base => $basedn, filter => $revattrfilter, attrs => [values %revattrs]); $mesg->code && die($mesg->error . "\n"); foreach my $entry ($mesg->all_entries) { $reventries{lc $entry->dn} = $entry } # Go through and generate updates for the reverse mapping attributes my ($dn, $entry); while (($dn, $entry) = each %entries) { foreach my $attr (@attrs) { my $revattr = $revattrs{$attr}; foreach my $val ($entry->get_value($attr)) { $val = lc $val; if (!$reventries{$val}) { $reventries{$val} = Net::LDAP::Entry->new; $reventries{$val}->dn($val); $reventries{$val}->changetype('modify'); } $reventries{$val}->add($revattr => $entry->dn) unless grep({ lc $_ eq $dn } $reventries{$val}->get_value($revattr)); } } } while (($dn, $entry) = each %reventries) { foreach my $revattr (values %revattrs) { foreach my $val ($entry->get_value($revattr)) { $val = lc $val; $reventries{$dn}->delete($revattr => $val) if !exists($entries{$val}) || !grep({ lc $_ eq $dn } $entries{$val}->get_value($fwattrs{$revattr})); } } if ($entry->changes) { $ldifout->write_entry($entry) if $generate_ldif; if ($update_ldap) { my $modmesg = $entry->update($ldap); $modmesg->code && die("LDAP: " .$modmesg->error . "\n"); } } } --------------050703040907090602090901--

1 0

RE: Re: (ITS#6952)
by quanah＠zimbra.com 01 Jun '11

01 Jun '11

--On Friday, May 27, 2011 4:47 AM +0000 Srinivas.Kondamadugu(a)mphasis.com wrote: > Any help here? The ITS system is for reporting bugs, not for asking for help. If you need help, use the openldap-technical(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6961) back-bdb/hdb search performance issue
by hyc＠OpenLDAP.org 01 Jun '11

01 Jun '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc See this thread for background http://www.openldap.org/lists/openldap-technical/201011/msg00146.html Currently when returning the entries in an IDL range, back-bdb search.c just iterates through all the values in the range. If a lot of entries have been deleted within this range a lot of time is wasted calling into BDB to fetch entryIDs that don't exist. Strictly speaking this performance loss can be avoided by simply using a cursor on the id2entry DB, and using DB_NEXT to fetch the next entry that exists. However, while that approach provides uniform search performance, it's also always about 2x slower than the best-case where we just iterate through the IDL. Also if we keep a cursor like this open for the entire search operation, it will leave all of those entries read-locked until the search completes. (Note that an MVCC approach, like for back-mdb, would not have this latter problem.) The current patch continues to use the IDL iterator, but if the next iterated ID comes up as nonexistent, then we check for the next ID in the DB. We use the same approach as the online indexer to avoid taking any long-term locks: create a cursor, use DB_SET_RANGE to get the next ID, and then close the cursor, thus freeing its locks. This way the ideal case (all consecutive entries exist) remains fast, and the performance hit of asking BDB is only incurred when necessary. Testing shows that search performance remains uniform and within 1% of the ideal case.

1 0

(ITS#6960) Out of memory erro occurs when running LDAP
by ArunPrasathSevugan＠oracle.com 31 May '11

31 May '11

Full_Name: Arun Prasath Version: 3 OS: Window Xp URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.225.129.57) Hi, We have a tool integrated with LDAP to load all the users in Cognos reporting. There are about 5000+ users and while running LDAPCONFIG we have been getting out of memory exception issue. In the task manage I could see the LDAP is using memory of around 3 GB and finally errors out. Please help us to load the 5000+ users. Thanks, Arun

1 0

(ITS#6959) ldap_dnfree not mentioned anywhere
by frank.muzzulini＠comsoft.aero 31 May '11

31 May '11

Full_Name: Frank Muzzulini Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.221.120.78) Hi, Reading the documentation of ldap_str2dn I was wondering how to free the allocated DN. After browsing for a while I loaded the latest tarball to see some example code and found ldap_dnfree. I re-checked and indeed the function is not mentioned anywhere in the docs ("find doc -type f | xargs grep ldap_dnfree" found nothing). Regards, Frank

1 0

(ITS#6958) slapd segmentation fault with TLSCRLCheck all
by alex.deiter＠gmail.com 26 May '11

26 May '11

Full_Name: Alex Deiter Version: 2.4.25 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.66.145.56) FreeBSD x86 and amd64, OpenLDAP 2.4.25 configure option: $ ./configure --with-threads=posix --with-tls=openssl --disable-dependency-tracking --enable-dynamic --with-cyrus-sasl --enable-modules --localstatedir=/var/db --enable-crypt --enable-lmpasswd --enable-ldap=mod --enable-meta=mod --enable-rewrite --enable-null=mod --enable-monitor=mod --enable-accesslog --enable-auditlog --enable-collect --enable-constraint --enable-dds --enable-deref --enable-dyngroup --enable-dynlist --enable-memberof --enable-ppolicy --enable-proxycache --enable-refint --enable-retcode --enable-rwm --enable-seqmod --enable-sssvlv --enable-syncprov --enable-translucent --enable-unique --enable-valsort --enable-bdb=mod --enable-hdb=mod --enable-spasswd --enable-slapi --enable-wrappers --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/ --build=i386-portbld-freebsd9.0 slapindex segmentation fault when option TLSCRLCheck all is used in slapd.conf: TLSCACertificatePath /etc/ssl TLSCACertificateFile /etc/ssl/ca.crt TLSCertificateKeyFile /etc/ssl/server.key TLSCertificateFile /etc/ssl/server.crt TLSVerifyClient allow TLSCRLCheck all # slapindex -v Segmentation fault (core dumped) # gdb /usr/local/libexec/slapd /var/tmp/slapd-49225.core ... (gdb) bt #0 ldap_free_urllist (ludlist=0x2) at url.c:1515 #1 0x28c9b0b4 in ldap_int_destroy_global_options () at init.c:485 #2 0x28c7efc0 in __do_global_dtors_aux () from /usr/local/lib/libldap-2.4.so.8 #3 0x28cabf1c in _fini () from /usr/local/lib/libldap-2.4.so.8 #4 0x281d4538 in ?? () from /libexec/ld-elf.so.1 #5 0x281d4538 in ?? () from /libexec/ld-elf.so.1 #6 0xbfbfea38 in ?? () #7 0x281a9100 in dlinfo () from /libexec/ld-elf.so.1 #8 0x281a9260 in dlclose () from /libexec/ld-elf.so.1 #9 0x283a81b1 in _sasl_done_with_plugins () from /usr/local/lib/libsasl2.so.2 #10 0x283a18f0 in sasl_done () from /usr/local/lib/libsasl2.so.2 #11 0x080c7a3b in slap_sasl_destroy () #12 0x080a4d3d in slap_destroy () #13 0x080e4553 in slap_tool_destroy () #14 0x080e6147 in slapindex () #15 0x0805b665 in main () (gdb) f 0 #0 ldap_free_urllist (ludlist=0x2) at url.c:1515 1515 next = ludp->lud_next; also slapd segmentation fault when slapd service stopped: (gdb) bt #0 ldap_free_urllist (ludlist=0x2) at url.c:1515 #1 0x28c9b0b4 in ldap_int_destroy_global_options () at init.c:485 #2 0x28c7efc0 in __do_global_dtors_aux () from /usr/local/lib/libldap-2.4.so.8 #3 0x28cabf1c in _fini () from /usr/local/lib/libldap-2.4.so.8 #4 0x281d4538 in ?? () from /libexec/ld-elf.so.1 #5 0x281d4538 in ?? () from /libexec/ld-elf.so.1 #6 0xbfbfe9f8 in ?? () #7 0x281a9100 in dlinfo () from /libexec/ld-elf.so.1 #8 0x281a9260 in dlclose () from /libexec/ld-elf.so.1 #9 0x283a81b1 in _sasl_done_with_plugins () from /usr/local/lib/libsasl2.so.2 #10 0x283a18f0 in sasl_done () from /usr/local/lib/libsasl2.so.2 #11 0x080c7a3b in slap_sasl_destroy () #12 0x080a4d3d in slap_destroy () #13 0x0805bc92 in main () (gdb) f 0 #0 ldap_free_urllist (ludlist=0x2) at url.c:1515 1515 next = ludp->lud_next; without TLSCRLCheck all option in slapd.conf/ldap.conf slapd work fine, but without the CRL we can't authenticate clients on their certificates ;-( ldap.conf: TLS_CACERT /etc/ssl/ca.crt TLS_CACERTDIR /etc/ssl TLS_REQCERT demand TLS_CRLCHECK all URI ldaps://server.domain.ru BASE dc=domain,dc=ru RESTART yes VERSION 3 SIZELIMIT 0 TIMELIMIT 0 TIMEOUT 30 NETWORK_TIMEOUT 30 slapd.conf: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/samba.schema include /usr/local/etc/openldap/schema/dhcp.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/sendmail.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args TLSCACertificatePath /etc/ssl TLSCACertificateFile /etc/ssl/ca.crt TLSCertificateKeyFile /etc/ssl/server.key TLSCertificateFile /etc/ssl/server.crt TLSVerifyClient allow TLSCRLCheck all allow bind_v2 sizelimit -1 timelimit -1 modulepath /usr/local/libexec/openldap moduleload back_hdb database hdb cachesize 1024 directory /var/db/openldap-data dbconfig set_cachesize 0 67108864 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 suffix "dc=domain,dc=ru" rootdn "cn=manager,dc=domain,dc=ru" rootpw "passwd" index objectClass eq access to * by * read sasl-authz-policy to sasl-regexp gidNumber=(.*)\\+uidNumber=0,cn=peercred,cn=external,cn=auth "cn=manager,dc=domain,dc=ru" sasl-regexp gidNumber=60\\+uidNumber=60,cn=peercred,cn=external,cn=auth "cn=manager,dc=domain,dc=ru" sasl-regexp gidNumber=(.*)\\+uidNumber=(.*),cn=peercred,cn=external,cn=auth ldap:///dc=domain,dc=ru??sub?(&(gidNumber=$1)(uidNumber=$2)) sasl-regexp uid=(.*),cn=(.*),cn=auth ldap:///dc=domain,dc=ru??sub?(uid=$1)

1 0

RE: Re: (ITS#6952)
by Srinivas.Kondamadugu＠mphasis.com 26 May '11

26 May '11

This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1C29.1B3F5374 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Any help here? Regards,=20 Srinivas Kondamadugu MphasiS an HP company |Ext. 51-41119|Mob: +91 9764401128 | email - srinivas.kondamadugu(a)mphasis.com |=20 > _____________________________________________=20 > From: Srinivas Kondamadugu =20 > Sent: Wednesday, May 25, 2011 2:15 PM > To: 'openldap-its(a)openldap.org' > Subject: Re: (ITS#6952) >=20 >=20 > Hi, Please find the configuration files > Regards,=20 > Srinivas Kondamadugu > MphasiS an HP company |Ext. 51-41119|Mob: +91 9764401128 | email - > srinivas.kondamadugu(a)mphasis.com |=20 >=20 > << File: (ITS#6952).zip >>=20 Information transmitted by this e-mail is proprietary to MphasiS, its assoc= iated companies and/ or its customers and is intended=20 for use only by the individual or entity to which it is addressed, and may = contain information that is privileged, confidential or=20 exempt from disclosure under applicable law. If you are not the intended re= cipient or it appears that this mail has been forwarded=20 to you without proper authority, you are notified that any use or dissemina= tion of this information in any manner is strictly=20 prohibited. In such cases, please notify us immediately at mailmaster@mphas= is.com and delete this mail from your records. ------_=_NextPart_001_01CC1C29.1B3F5374 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7653.29"> <TITLE>RE: Re: (ITS#6952)</TITLE> </HEAD> <BODY>  Any help here? Regards, Srinivas Kondamadugu</FON= T> MphasiS an HP company&nbs= p; |Ext. 51-41119|Mob: +91 9764401128 | email - srinivas.kondamadugu@mphasi= s.com |=20 <UL> _________________________________________= ____ From:   Srinivas Kondamadugu  Sent:   Wednesday, May 25, 2011 2:15 PM To:    </B= > 'openldap-its(a)openldap.org' Subject:    &nbsp= ;   Re: (ITS#6952)</FON= T> Hi, Please find the configuration files<= /FONT> Regards, Srinivas Kondamadugu</FON= T> MphasiS an HP company&nbs= p; |Ext. 51-41119|Mob: +91 9764401128 | email - srinivas.kondamadugu@mphasi= s.com |=20  << File: (ITS#6952).zip >= > </UL> Information transmitted by this e-mail is proprietary to MphasiS, its assoc= iated companies and/ or its customers and is intended for use only by the individual or entity to which it is addressed, and may = contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended re= cipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemina= tion of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailmaster@mphas= is.com and delete this mail from your records.</BODY> </HTML> ------_=_NextPart_001_01CC1C29.1B3F5374--

1 0

(ITS#6955) smbk5pwd: Update shadowLastChange
by fumiyas＠osstech.co.jp 26 May '11

26 May '11

Full_Name: SATOH Fumiyasu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/smbk5pwd-shadowLastChange.patch Submission from: (NULL) (113.197.240.138) This patch is for smbk5pwd overlay to support updating shadowLastChange attribute in shadowAccount. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by SATOH Fumiyasu <fumiyas(a)osstech.co.jp>. I have not assigned rights and/or interest in this work to any party. I, SATOH Fumiyasu, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#6954) pcache crashes when bind-caching is enable
by ralf＠OpenLDAP.org 26 May '11

26 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.211.118) Submitted by: ralf The pcache overlay can crash slapd when bind-caching ("pcacheBind" in slapd.conf) is enabled. It turned out to be a race condition with the consistency checker background task. The task might free and (expired) cached query while it is still being referenced by a bind operation currently in progress. Fix is coming.

1 0

(ITS#6953) pcache deadlocks when refreshing cached queries
by ralf＠OpenLDAP.org 25 May '11

25 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.172.234) Submitted by: ralf Under certain circumstances slapo-pcache causes a deadlock in slapd when refreshing a cached query. The reason seems to be that, slapo-pcache considers the refresh search, issued from the consitency checker task, to be answerable from the local cache database (this only seems to happen when the pcacheAttrset contains the "objectclass" Attribute). slapo-pcache will search the cache db with the response callback pointing to be_modify() (indirectly through refresh_merge()) of the same database. When using bdb/hdb as the cache database this cause the task request a write lock on the cached entry with in one bdb transaction while already holding a read lock (from the internal search) through another TXN. slapd is deadlocked after that. See below for a gdb backtrace taken from that situation. The fix seems to be fairly easy. Just do not lookup the cache db when refreshing a cached query. It doesn't make sense anyway. I'll commit something for that shortly. #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007f2b88eaf519 in __db_pthread_mutex_lock (env=0xa5ebb0, mutex=<value optimized out>) at ../mutex/mut_pthread.c:318 #2 0x00007f2b88f4252e in __lock_get_internal (lt=0xa5efc0, sh_locker=<value optimized out>, flags=0, obj=0x14060, lock_mode=<value optimized out>, timeout=2169475480, lock=0x7f2b814f93a8) at ../lock/lock.c:953 #3 0x00007f2b88f4350c in __lock_vec (env=0xa5ebb0, sh_locker=0x7f2b858acf38, flags=0, list=0x7f2b814f9360, nlist=2, elistp=0x0) at ../lock/lock.c:136 #4 0x00007f2b88f43c48 in __lock_vec_api (dbenv=<value optimized out>, lid=2147483672, flags=0, list=0x7f2b814f9360, nlist=2, elistp=0x0) at ../lock/lock.c:84 #5 __lock_vec_pp (dbenv=<value optimized out>, lid=2147483672, flags=0, list=0x7f2b814f9360, nlist=2, elistp=0x0) at ../lock/lock.c:66 #6 0x000000000052a5d3 in bdb_cache_entry_db_relock (bdb=0x9c7a20, txn=0xa66670, ei=0xd71720, rw=1, tryOnly=0, lock=0x7f2b814f94d0) at ../../../../servers/slapd/back-bdb/cache.c:198 #7 0x000000000052c1e7 in bdb_cache_modify (bdb=0x9c7a20, e=0x7f2b85445068, newAttrs=0x7f2b8267e258, txn=0xa66670, lock=0x7f2b814f94d0) at ../../../../servers/slapd/back-bdb/cache.c:1231 #8 0x00000000004f3f2d in bdb_modify (op=0x7f2b8167a430, rs=0x7f2b814f9820) at ../../../../servers/slapd/back-bdb/modify.c:711 #9 0x000000000059e458 in refresh_merge (op=0x7f2b8167a430, rs=0x7f2b8167a370) at ../../../../servers/slapd/overlays/pcache.c:3275 #10 0x000000000045c207 in slap_response_play (op=0x7f2b8167a430, rs=0x7f2b8167a370) at ../../../servers/slapd/result.c:505 #11 0x000000000045dd28 in slap_send_search_entry (op=0x7f2b8167a430, rs=0x7f2b8167a370) at ../../../servers/slapd/result.c:997 #12 0x00000000004fbfd0 in bdb_search (op=0x7f2b8167a430, rs=0x7f2b8167a370) ---Type <return> to continue, or q <return> to quit--- at ../../../../servers/slapd/back-bdb/search.c:962 #13 0x000000000059d86e in pcache_op_search (op=0x7f2b8167a430, rs=0x7f2b8167a370) at ../../../../servers/slapd/overlays/pcache.c:3037 #14 0x00000000004d9ba5 in overlay_op_walk (op=0x7f2b8167a430, rs=0x7f2b8167a370, which=op_search, oi=0x9c7430, on=0x9c7610) at ../../../servers/slapd/backover.c:661 #15 0x00000000004d9e52 in over_op_func (op=0x7f2b8167a430, rs=0x7f2b8167a370, which=op_search) at ../../../servers/slapd/backover.c:723 #16 0x00000000004d9f3a in over_op_search (op=0x7f2b8167a430, rs=0x7f2b8167a370) at ../../../servers/slapd/backover.c:750 #17 0x000000000059e9bb in refresh_query (op=0x7f2b8167a430, query=0xa66580, on=0x9c7610) at ../../../../servers/slapd/overlays/pcache.c:3371 #18 0x000000000059f03d in consistency_check (ctx=0x7f2b8167ab60, arg=0xa61910) at ../../../../servers/slapd/overlays/pcache.c:3492

1 0

Re: (ITS#6952)
by Srinivas.Kondamadugu＠mphasis.com 25 May '11

25 May '11

This is a multi-part message in MIME format. ------_=_NextPart_001_01CC1AB8.7233BFF9 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC1AB8.7233BFF9" ------_=_NextPart_002_01CC1AB8.7233BFF9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please find the configuration files Regards,=20 Srinivas Kondamadugu MphasiS an HP company |Ext. 51-41119|Mob: +91 9764401128 | email - srinivas.kondamadugu(a)mphasis.com |=20 <<(ITS#6952).zip>>=20 Information transmitted by this e-mail is proprietary to MphasiS, its assoc= iated companies and/ or its customers and is intended=20 for use only by the individual or entity to which it is addressed, and may = contain information that is privileged, confidential or=20 exempt from disclosure under applicable law. If you are not the intended re= cipient or it appears that this mail has been forwarded=20 to you without proper authority, you are notified that any use or dissemina= tion of this information in any manner is strictly=20 prohibited. In such cases, please notify us immediately at mailmaster@mphas= is.com and delete this mail from your records. ------_=_NextPart_002_01CC1AB8.7233BFF9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7653.29"> <TITLE>Re: (ITS#6952)</TITLE> </HEAD> <BODY>  Hi, Please find the configuration files<= /FONT> Regards, Srinivas Kondamadugu</FON= T> MphasiS an HP company&nbs= p; |Ext. 51-41119|Mob: +91 9764401128 | email - srinivas.kondamadugu@mphasi= s.com |=20 <<(ITS#6952).zip&= gt;> Information transmitted by this e-mail is proprietary to MphasiS, its assoc= iated companies and/ or its customers and is intended for use only by the individual or entity to which it is addressed, and may = contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended re= cipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemina= tion of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailmaster@mphas= is.com and delete this mail from your records.</BODY> </HTML> ------_=_NextPart_002_01CC1AB8.7233BFF9-- ------_=_NextPart_001_01CC1AB8.7233BFF9 Content-Type: application/x-zip-compressed; name="(ITS#6952).zip" Content-Transfer-Encoding: base64 Content-Description: (ITS#6952).zip Content-Disposition: attachment; filename="(ITS#6952).zip" UEsDBBQAAgAIAPmyjTwmALxUVhYAAOlMAAAOAAAAcHBvbGljeS5zY2hlbWHVXHtTG0mS//v4FLXg CGBCCCTA2J7ZiZCFsHUrJFYS4/FsbGwU3SXU51a3ph889mK/++Wjqrq61YDk2SPuiN2xHlVZWfn8 VVa2dsSb0VJFg/PO1Qex/HZ7GPpyeZiq5E4l6WEayqV/mHpztZCHy2UcBt5jk9827kSredZsN09F +6h1dHh0ctg6hpcf2scfTt6Lb3mSid7DUrzZ2tkR03mQivs4+Sbg36WEr+KZMOuKSTzL7mWixE/z LFt+ODy8v79vxvAt8tKMk9vDn5tABQl14+VjEtzOM1jp6OQAVwbiqqB1EeeRL7MgjnCK6IShoPGp SBTtyjekxsoP0iwJbnIcLWTkizxVIohEGueJp+iTmyCSyaOYxckibYj7IJuLOKF/4zxDKovYD2aB Rys2BG5iqZJFkGXKF3EUPgqZCpnD8CT4J3x08ygyh12kcJXfgFjFIPBUlCrDXUd4sFUUU4ayC/lb FJ+8k0Eob0JiFYnNAng96Hd7w0lPf4YUsnh5EKo7FQo/SJSXxYkmp0Rp43ECfIeZSiLYBAx/hLe0 NVcbhmHShmamOc8WIWqGdhEnSC11NLTX3Sfd9CMkrjLQsxeo7FHsoe72ST9XoZKwrVTBNnLQlWdn p5nM1EJFmbhRYXzf3NraEedqFkQBrzNL4oU4T+QMB8xVIg/QWg6WMk3B0PwDNtaDozOxJ7XpRWKZ xLdgB+n+1s5/XOmRwDqORB0LMqFzLa5ApbDmF9S5eshgx8W6n9V9qLLs4Ep632TifwByy3u/O1fe t8vYz0EfKvOI5W4Mu4/A/IwmSVtoJ2l+81+wDuhJeHMZ3SqxF0RemPtBdCt8BfRhPWDUWJuI4gwE T/IWwzgDg/biBUjIB7tC5mFzfu6RTsGQ/wSjrkG095r/BIQpPEk6/xNwNlQZSeUL/AdX/JTE+VKs 8/efTTEBG4f4MFfBYmvH6PeAtbHZ3zAGkwsbYCTe1g7EC5B9+kF0lkkQivZJA938dF1agyboMsji HLb+nX+TPBKXgZfE6WMK5pd+P6URmNCNSswmTlBtddTWNMPKn4+iPnjW8N81s4cM15yAJ+WFAV6q RaxZobDsx15OfoaxJRIVbWIQhC8cY5XgpmBqdwH5A9EB0qliyzvGN+OLrjh++/asKcTHR5yLARGN jBgor9AQSnpzIsNxEux6ibEanSabS2QBouhyCbuiqLeU6FAYhmOIZYnoX42FF8pggVskOvfzwJsL iDwwBmyUNkb5ZS7vFEQLFXEQh43cUDD0wjhVfoM2i6s9QecGHU5pWjXTIcBIzwMdyMhjxyMyWhrv mlrq5f2nFAzutRcaZaQmVNvg2Ytug0ipBEax7mT6DbIdJqq9fm96sQ/rMzGZ8k7wraF7i96dNtHf MkViZcWRBPlLsZAg5zCNi/RQx5dM6zbx3N7IVh0KdzIMOGJJWPMhWOQLsqDgAbJplM15AdwBcgQi zpeQ0VHAYBmh9PAVav8mjSFIclLljThcktkQoSxYKNh4nwwc0vkSjBfCi0Q5xJTyV5hGsDBTiQI1 EokFDIYZIS6L4TogGaqFXhbEGeGk7WqaaW5bR1OQwlOCPV6eJGjA1VU9IAKbBQuCmbArrSInCUPy nFECxheHrcA/kDegKemB/MHXmzWLVbx5Mpd+fO+Glk2WTWk2pf2mG0Eqi5BnKArlAIEqsZwmFhhh SDlNE9sEOmztdPTe9WQbRzn+oT58lXpgx7ApQkXVWAcxi2SUQL5OC5/wwAaTOEzFHCRloipbck4C wiDhLwCIQIZImPgAub5X+F+icW4RV4fkKq6SOIu9OBR7GNv3xY1EUn6hB7RQDEs+2lNMRIIFhlmy NAyveRJkhOAoOzhTtat8g0AHbhbMAI7mYYYORmTMFoQH0iJnJvOUEC/Blm8gXqDNZrFLEmMJyggk GCQYddmTYqGiGYWcivBAzXaZPJW36HCgP/At/h6Ft5C+oq0hrb9BgAHs4v8d357C6AkdKljCGBoq adExbT5+CABI7Oo+gkKYBZ4IIBKzE+0G0I24VRHkR0CV4L+3RsydslS0ucSc3yCRgLaCgirnALQJ GUSF0XCI0laQEHBeISkzHUV1PLYyg6NNQgcGGTIdO5DjpV6akt88Dn27j+oKhJHZVlAvCyJK4sOc isJMmizgNuzbrCKmj0tYikStjxAAXjX8GJEcuigGLfOLOAT8jXaDzOFoy6/ICkr6ZFNQciVquGi2 BI6wrLhRBHeaEo1IQpbV+c9ZK9bKoGUqkgh00kCYAEc85BqE8CAXy1A1amfo3KJnIHU6NwERFJs1 P7s+oHn7Grct9uD8e9x822w1T/D/bdhd+6z5Dl63tjS27Vz2xK673139Te+v151Bf/pVC6nvgyXD MVIllzIDMKSx6NfhtPNraZXWyVt42Tptttrwpnn8TuxvsWDbJNjLIOrclqRayM+Rb75AZMqoLY58 jbMWOeQMBSf+FKEOhDMVcfZzjripFpQVJ8YtDSyLpeANHFaEhnENcUR0zGI4NE0hDvsbyLRdlSlv dUWg4PvqdlM5ts/M0P7w06B38EtncN2zoj1m0cqH7xItZET4gC1XalkqvxyDnIxpgdSLQgUDD9hH AFDl9P1RSTVEx48Vz9PkiTK+P2o4c0n14A2AWhDqMKJBD/o91zFKq52Ha9+0WthAj8creiS5voYe T0iP/egzhGxIzfWqTJfKQw2xOg08LdRKsa5ABUhJa7MIpXoBN3b8EaU2aNGSxXCiwJnMwHOLU+7J 5nmqQx4RShTS3EBvJ1W9WTm+hupOSXVUX/krWCQAIS3R/56OzkcfsMqSBgidqJLCJ03Q5SNk7Qc0 3VH/HCy/h0kRXrK/EUSWROV3pklgReyFAUApyOwiVFFD7JAzo1UgkJhLhJwqgZSuMm/fwByWKUEd jaeNHfkizjPgDYa7ALT5r/IG7LFMqDuFuozz2zkbC/xvoWREZ29MWMAEiEGjA0hfSh/C/TwhcGeC SrkyCXjOnu+QCuZ0TntMQ0+35/BhU7tGQPl9loeEK9Igy3UiuCfAVUqtMBbOTMnjMtP2CmMiG/Ma AuwM0I0ewF+SP2FVgdb8V71TBpGPG1GMyUtLGtWZ4/gdHNRsgIWoG2IuQ7kYLtDFpO+r9TKXxtBV n9w92m3YpUkfuATxgNOBDw2UcZUOzzOVkt3WrrMhUiMjfCy5Mw2jYWXW0Af6mcUoejQqJ6KqCFUR cRYoes/P6QMJuk3nTryyRRMdA2QKitzHKUZ8eAxE5RRsE8vtOpZdRl5mu5Zl0hYf04OsYRlJVJYn WJIXKkmoIjTLU+PVFnmsH7xOq8HLjSSvEb/eGnQ2UNEtloVoy1/QAVasiJwIBeQ3qtZZ4Aw8eEBi IjJFcirCk4PobpSF+rIGtpVPICsOEMVmrcKKQtqEsRki4Jh7/2l1FwaiSVhL5ZrDE9Z6H6Rqv1H1 kgaEEghcVC6PI2uQVYTiqrrYJ4TvgGo3bPCruMkU3Qu1gF+B2yNT4MH7wpil4m/au/sbGOTbGjTL pvEa1nhG1sjF9i8yiSjufw8YMhj3RoH2ldaimw20enUxiPMbvuaD6j2vDektxZpBWrIojgE6OUSU H/CQhPkMptij7fdDZbBszUCqNc4h0Cz8AlROF5BDDVS2X5sgb+AxgdvvOkSeVU2kpK/XMJN3ZCaf IKKoDmbnQbAIsnUMpTAQrL3SrQJbgOPbAJOIkIlOGgJoFas1knOhVcfvGS+7xoJ2hpqdySDcQPzv quKvyOE1FPCeFDCIvW902fwsMmownAq4vs6S2J6Or3vbjQJjlCIcwkENVuo0oA+u0kGyVq+mTopV SSp9oXAV3ZZTxUQtllnK2LgmajgTiVDdZLpzsgtjSZ2c6QKG5n/wkLx90RlMWCyqHLDMdUOdNEi6 ZeN2+DZJlHmHPMa3TAmW4TY6Zr2vmp3W/oq53cRxCKeCzcztWWtrHbnmdp5zkP7OWlIJo4Ovg1Ke c3eTKLIY4AbewD1hUH02vX9LZYS5epKjHF6E1DSSYW1Tlic7pd842aQ0ePSEgo28XyOutFqi7E+b BfUnHL/sA27Zq2QML4Sd5h8qlNCkpb4xwEMFzyIQZy54S2WsQgE2/we3EZZUNlFqq6aopUX7Kvrk 4q9esRuD6dLF2R3W7v5IvXLFZ2a8BJeflnlyi7c12BBDfUj8JdhHjqs3SqWMiO+00pzuw7CcUEnS sUcXo/6msb2U8TRSmxmzpjRF3OC31I/lePSTzGyi+5XCdJ0aXsUKdJ0a8GmX+ole8mrqDJKFLzBc 4PiN+DolrMtC5AYlkFGQOEVIkxQhXgcJwmIM17pSXDSdaSCxcjig27CkLsRWwuu6Z9Xnkj1vSFdN 9QHj95wwadGAVd6fyJdgl7gnuvyacWFcPZMIcEup3VNavSiZ1tozjNT1Oz4KY7eLxyW2AgHR7ZpT PzQXtGCdYLMh2DULkXl6QpB6D8QcnaLovjXZTb+nptJareRby3sNtMLV/A7WMa9hE8+ZfFG6AoOl Uz9bA5ZqS5qP76NymZ06I00tVpnB9v6WrDjDvOH2R1FQcVsJ1qo0rjqisXd9V1ZnPxhGqP+Pa8Pu la68SaljFOjpoxYzZpiCUzduJ0gXmyh95RqgooDX0DxfBkzkTF1iTffFixyjdHAAlDgKRz2AT5Sr 5Xys1zVNOF3KMKaSbsaqj9S9c1+HcY/LymwS69fTpAlJRYza/DK0tVLQLKTxv6wB8fnK6YYl0Zc7 X02XY0UdeKef6oBzYDocwlj6VBtccNMspR7qLfRN06O+7viHkf3evpjlEcXHJoq8WuHTeQX8Aevs WKxr7zIl7r7Vcy3aw+CJTT2co+AzXbwJqPPI6blgIqVqbeo0FOIwNAM88tpF8CDIkBTbf1CpH4x4 gH51Z1S+FT+Y9w39/geqgesaWUPcxYEvfpDJLajDitpZM4VwFfqmhI69Qv+YXHe7vclEt9xx+926 Ef/sFP95/940NZRL6KxybXLW4jyZqt4DJLF+59QxuzUAjq6LnvcmXbE7qLOOIEozCUCNwvn2k7ah WaqaL7dbcJNPzUbbzkaLnXI/C+0XkqVxjOsr7LDX7zrXv/YH/c74q35/2fkK9Cst4fs6hLVYY9We G+E23ZD3lHqSbAtSqStGNypxMq+0uJhbaTWbIRnWvm5BogSIbVe6bRcO/6ZbLrWFEbe/CRG6zmHM VnGYSlTIV4LzYGkaRxCeyMhcWicZtqTJRE+ldqBnVGEjXfspZayphevJlNVQ9D7tVzXEHQzijVOu fVPqE+C3pSDzRhNxC/c8rFSk5Y8qhUP+0BT1mM6bmsKL5UifJ/h93eGixI7FYDy+kp75wyJZWJs8 Xu0Pq+nCE9hKjl2ZttnsieZLakwrNaWZsvkCbBjtWLf5uX1qOpK5s/DJlxihG8EaO1hAKk340ZqX e+psK6IzpNJy94E1TJl8GixUg+0WxOfR8RFVo79xlGDfa0NpWG2DwEtkxoi4G4XHT/KbHu5At8Ud Y0ioF3WhlNHSkfckwA7zurY2j6I/drU9YhJM4QyelPerqy6MdLB7xIW7JGLTeneD3adPSI30ielP N2vDONIYrknI61HXEEreh1GBGu6wj0wXiEsJ1nRjLo36DVSQHPhmphnRJFIgf/CTIWEX+ll/yz0K K1+j2WTULWHp8WNZ/XPdNEKz955tvdPNH5VuSB1Gl5nuHNiDfJxkBH/2OSBpnN607ZVOo2Iwq2+i RCBBj/iUeidh9rbbrIhndxUVF5/WnuuVyA8s2JZHdqqGQUaOgB1KP6K83TU/YFf30VHr6Bjkcto+ +q0ejWuFsrjpcZIDPLqC3FO1wHzucXkX8R6YR1Qc0VWK1cT61tdyd6hzd8eX3amSiX60xAqA05bt ijO2ag24QSAQ+OPWVnIF3Rj+xMpYU7B3hsah21XBrVNihVyY0ZUZn1FQHc7ZXNzrRy+KI4fToFM0 4JrhzkWrfnDzqTOK0yMIkazSLstNLRhGKh2KaNxPn1DemjEOYLTC2DVfMtBDL7LbdrfLEtH7tZMs ztRt0fhgJVJlqKkHjcbnvTGgv+qgEXbYg92VBq+BTE/sWAdSms+uJ51PvaLiNbL1gX1jD8f16eSl 8qyWir5Q0cUayVRYQETKdrXzWzsC+8bqLmS4Bi/whAtqLSrxtvvLuYbtiCN28Bb+85u5BS9TNgua my+XGXweVkZAMXw0mBFm8bOxTxWqsDKTR0hA3/fYJdazvrMV61sR/VM2KCOOhqtS/n9tgCeiglzW MT0IdYulfRTNvfcp18tLdwPraej9ioYc3p7QTZkdjg3P8+Sw9X9Eey9ristbzzYps5akmOsTCl5k JeouiPMUvKrcogwu/Au6bFq0ppRo0UMdCXizfmgdn3832AhhOCKv2wBvcjjBsK4tbOp8HF44UMGc mf7MzrS9s60BFUIrfKcbv/ClLzOpZ9Jg/vuz+Kki8wmzIysdAW+xGrn6QC3s8G/ji267fdr+u4GB BQtAPsoXoEIPyyjw9yO3lfES9slT58CrXnoE+EfInyi5Ax+YWwDAwnUoxjF2TdcjopuVzZ0oI/Ny v+OLNJytBZXH38AoX57vys64sVYYq0YvoMX1Y+UKMfYyvPWA1VC16/Oryf3bWMbVC2vSXFndVvtI 7c8okLnXrFi6hbGm9HPpEUjjKwxvnU5Fo0qd+rSjlXy30tmvG7tNYZHOCs7DgTPzWAYWIhYYhmhD nLttFRCfcVUJZlwLI2AHcDKMlPLpIR7pc/82tgljFMWnGTXs5s3oh6i4fpknyzhVK9TMgQZE+Oly aiaukwDaRysJwD5PsBL8nThHubkAxTVhnfTNMWPDKH1ytH6Ufiuqp/3NEuotzqykrLT+qhRBle6f W0+0rRXRunyulVzr2CuuQA2FOhY3y7PrpU4W+VlRS3k+Lc5CiR5h7/3EHl3Y4K3a/hPNcLZlSz9r vnKaqlykRvbGyBxPzOWrAerYk8y34tXegnVU2F5RIe27Rnd6k1R7WQH6TieaO7v+bmhn/cuhPwRF ua/UVsLonFuv0GUc0K9AxJWqSKpnVarb9mjLVZP1JH28IukyZzUiX4sRzcSqzH2+eswDbHYfyo0d otX+fvFv7Zzjz1VIcEPK2L/gXVDxNFX590BMfd8tyOpbCP24NVZZsL7GN3b4g0fmrnm7MxH9yTY+ 5x7wA+rTzz3RHQ2n4/7H6+lo3KAPRuNPnWH/t860PxqKz73DCXw27l2Ne5PecDohSqMxEBKTq9Fw Mhr3zsXHr2KvfyE6w6/7TKM/nPbGw95UTEbdfg8E3Bmel74gMr3hp/6wx5h+2pn8RVyMxt2eOO9P uoNO/1J0BgPxpTMed4bTfm/SEL1fkYsJLX95Nej3zrma2x92B9fnSAW2IYajqRj0L/tTYGw6QqYM ka/AQmdKfFxPYKMX+FJTgKUvzZbHvf5QfOnD6kgLvkMOe0Rp3P/0eUoc4DvNBT84YhlFwpe9cfcz vO187JOBwYSL/nSI3F/gZHHVGU/73etBZyyursdXo0mvycZQ/ODCxPza0sY/xVDzKzK6GcJ9bpR/ g6thfseKTQKCEni67nUpLAus6mP3Spy9a9grJPVAT2lIvtwFc+RbebRAxiT80zGI8pAI1fC4pYMX bm5t/Q9QSwMEFAACAAgAAG65Ppjh1fQHAwAAAgcAAAoAAABzbGFwZC5jb25mrVRZTxsxEH5OpPyH EXkpUkgQUtUKiQeOHqiEPiT0FXnt2ayL12N8APvvO/Zm6aEStRK7ijae+Tz3fFM4uziDMyHv0CqQ ZGu9SV5ETRZqbXAynsIKEYIRTs2z/s3bfajJg8IotAnAwN+vkcufMM9X140OxQ6EhpJRcP11DRXC I3k+eBRKVAYZmqQSURw4EZvRfNGfJmNtpUkKRywKssFWLCR5nPf//64O2u4CWB12aPluJL9x6APZ HThyaI0SbgdEdXbjKe2COEdGy+4ZkV+nVS5XRvlkF33ZWTgZC78JRfWrJgv7i1P4YHMtYX21Al2D Ix+Bi6+w5qxUaVkOeQtn1Df0uu7OjUYbweID+iI+165Bv0o6Iny+/PT5ePnh4vJmeXywWl09HPUQ 9FHXWoqIH3NvOSOUyeNCsiLwwbOxucP2T/QX7P7lwul/OJi+zpMLWKkK8txVImBfN10m+RWd5Hdw MWJ/k3FIda2fRqM9JU9a5HVR1AptZ3yU1O5Nxp4oKssAaU+WwooN+tlL2CmcGxQ+4lMEJ0LgNVNh BhgcSi2M6coYxAahtzrbrmXJHkE8kFZzeF74YkK9eb8PgsnhRQoom37DNaMaQvRkNyASO7ExdzBT AlpJTA8bVPM+IfcI/HBTPcaeJ/CX0muPkvewg+XNag34pAOn43UOnYCH32p2UcKB0+uLfH/LLmQ5 xZyIlBiCzutQdSXfHj2kwXZoG/eSFMK7w0MmI65hyyxYgvwZw3zRcxFLYpcZi3vGNZZNiMyacHSY rVxapdllji93hMti88YrfMpnw9FjmOH9IKPqO1uXhutbVIOch04kEwHvZyFVgzTYrSD/ylAKM+gi GnQNWbSprfIG92L57D7p0l2P94lTUpkacj2IF8iILjNElTS7ZL4SLfeLh2Qybkklg4aEgoGkjMhm tH2gO85zGC4oWs2SfrDY3MXluvRhMh58bE3k+z0blQiGXAflFnU7yPc48pPtYUbpxD0Ovl4c/8FE CnhrSN5Rij+FjQjNrRzWo1/FvI4/AFBLAwQUAAIACADvg54+Ig2vK+YSAABqUAAACwAAAGNvcmUu c2NoZW1h7Txpc+JIsp/bv6LC7g3jfTYGcfiYty9CDbibGAwsx27325gPslSAtoVKo8M2M/H++8us QxLosNzX7Ds6YsZClcrKOysrSzohE4+6o74+JT3mUxKYG7o1jk7IW3X/lnif15eOZXiXAfUfqR9c Bo7hWZcC9NKEx+ri+vyRNOvX13Wtfk20RrNx2WhfNltweau1btvX5HPkh2Tw7JG3RycnZLGxA/LE /M8E/noGDLFVQs2crcInAyj6900YereXl09PT3UGo0hJnfnry/+oAxZE1GPezrfXm5A0b26uL3Bm QE4TXHcsci0jtJmLjxDdcQiHD4hPOU+WQjWjlh2Evv0QITQxXItEASW2SwIW+Sbldx5s1/B3ZMX8 bXBOnuxwQ5jP/7IoRCxbZtkr2+QznhNkwqP+1g5DahHmOjtiBMSIANy3f4NbDzsSpshFDNPowbFN MrJN6gZUUacTE1hFMYUoO0eMoviMR8N2jAeHk4rIVjZcj4a9wXg+kPcQQ8i8C4c+UodYtk/NkPkS HSV7jDMf6HZC6rvABIDv4CdnLa0NRTDXhiSmvgm3DmqGc8F8xBakNFTrnXHdDF1ETkPQs2nTcEdq oLsr0F2jexYraSaUNDtQEjcci5nRlroh10joGy4YpZgM+LFDsjV25IGiwGwQMQKtIt+1gw38Chmi YcC1DwrEMYv69iNnlVtkABIxQnh4y6fgAhHwTzYInD57jgFCtblIYMgIApAe4bcCYm89h+KDnCBF iedTMHJqnUuazomHSkaCEAunQqkARwHZ04aBFgE/XKODnCsjQ7sFSFPoagUP7xDHZ9tFtD57tC1k E3lA1RoP7JGLQirBZaEtbZkbEuA21r7hbdBWEZHtmk5kcWsFM3BIEJkbQXaQK646IR/YE9gVmA1i RByxgkAk1FlxMcDEKArhH4DeRhfbkScD7IvPAY4B3uDTLbDgrrnFbnIoB5H4dEV96ppAUcg4VMak lM4QTTwItmq49m/CVs5BlSb1QpzXpRQ5Bq/m2LzI9xjomq04M+gzwL+7TjAFIYjC8K1AqMpGERnw BH/aZya1IlATIkQMMQ9gunRlu4L7fbpjhPzxICDbKOACU/8Q0Yo5DsgaFM0NDwTxawS+bHExSD+g 6AG2C3ccw11Hxhro4KJAm3ARy8Bdo+1xV/sm/4RjUghKEOiAGh7xwC3QI8G2XLwn7FDGQ4+GkeFw c3qywcakbXBEPn1kn5PImKdZdDQwGRQT8wPlhGsXbTGhqCBcbDBOYvwWHmoy8FWuEhARRS8OEi/i aYAjOtbnZDg/Jg9GYAs/WHwYkOF4MZiNBwsyn/SGg8Unoo/7+wOD8fvheDCYDcfvOT36/GdyN5n1 BqQ/nPdG+vB+TvTRiPxdn8308WI4mJ+TwcfpbDCfk8mMDO+no+Ggfw4Ie6NlX2J5t1yQ8WQBMf5+ uBjAjBOY+JPC8Qko0BecjCUkgMmdpAimvdcXw8kYUXwYzAbDMfn7EOZGVDCMNA44otnw/YcFnx9/ SRpSJAJOxHE/mPU+wB393XA0hGkB/m64GCPpd/gsmeqzxbC3HOkzMl3OppP5oH6E2eEIfZJHmYBg EnlsybUHaJZuwW18tr09Onkzu+sRTetol/C/LqkJ0DP+/Jw6kMJiP0TrNz/vYVEImtpVm9Qi27q0 zDOFtHF1Q2rL2TC+obWvSM0yAWby8E/AHA90rmFg+vMwdQMe7e9cYwtJuh9n0jmkKQhPgYJrdzSY FuwSzBac0uqzLZjZHvEpMwRnyKNda11dcdoVUeJxxbQRypRBwp1HhdyIFFoXQAE22AWAMF7axU/g A6RGtHqn3q43yFi/H5BTxmfpOUD1KVDQH8x75BTwIbpbIkaJicM0UEsH8Cs73CH44K9LnduBABxa OASh3r83QnMDAPNPYCsfYZnYqnfrTZi3WW+2u3DZ7NSbGvyot67JWWWqm4LqGjk1HBuCrxTS2NjS 0/jewA39nbh1lmUJlEh5DhXAkvI9ZjAvQ+iPeLJGRNW5aWpkDj41Glz8TR8tB8haPiealP9nlz05 1FrTYWIZp0eHRMdQaQMCsJhkzETDtQtrc0FrFVI7v7e0q+71f71C/q1Y/qYLAscFE3MLRS2GucRr wRlPtSJvJkaEoReZcyH2ow7my6nQUKHg2jEJAZIQwCpPzn84PRgtLEBX4LTO7uwVVFQgoiO1BwtV 23DG0faB+lmtiVHi8uFD5ynT3fLdfDFL3Z9HD7j+c9dBZe22279321K1IjY1b8RKxOY5sAbKixJH gST4sd5pNHiakwycFTDfTYyA20CU9rdEBjjjLQmfGFQgUAr5kEsnF61mt0vkI/DXoilxVzLaJkAd ONjJF5CZsdUMcZoiW1CZMs1qDn4VT+/A9A4zIeCEOWKStirHY9MEi5TBFxaVNmZN261kmteJf4To H1CV0Ik/xeUNrJ6L5udguKryJODXE3KTIsSnVBCDF7plAaognwwEIIaAiCtfFaO/s89ARGxqIh4W pJ9GzBMDdtK1RZFg0zB70nyAAgOIg2V8JWk2k9THooO5DWcJXl2FAohGEYB+FSEqc0EYc2g26PHb JFkEiQ2TvciXnqRq4peZ5xQM0PRtT+S/jBfHo48HmfKk2HROXradk4rG09BUyO1TqP9Nzj8UNdSF MgwKxDk1fHPzHhZ3tEi67TizxKB5iQUHyRpHz4HpF+Y6rWL8WqdE5yrfPUQB1E1B0IPZ1rAEzpKm IIiZgPzRXiszwSkU+KHhqPCTIV0Mq+CTT/cIloZFtOPYl2TqZgnpV3uk91ieNUi6ZTb97sJuN8pk fZ0ieLJaQXn0jj1naZ7CMBHjRAD8wXTfKLo3u8CGXNynDgQRfydo5LE1y4SEJQpYcSTB/2C711SN F0Lt6W2YS4sWqgsFQGKImPaDh/cZOBj8Ai46DahCyphopph4LmPgOSG+wrRayZRaasqQPi9wawtS Z1Ld5hMAoETBkj3gCvSUBAEtqbpWhhnYUM/QxYFKceg5L/vfqSdI7c54PstTdYXcUCYtlbGeAbYw tn5ETETPhlYojqBKMufcbPaNa2/oC0yr1f292SkzLZXVbFd2PnCBZM/74yIz2wOEkqE/lsXdD+So W8aRynQ+XUMyoj61CjWSgGQTHy7Q9pLl1+Yx7SpZvoW2kODQtbBnxnLknIICmSdg371kfiGgxsmN dyNAdCrw39Nww6yc1KwAgSWZIrYKtEKEb2eL3QLKbhLKAtWJKl7opIDyljs5SKoLsVWV5pZKT0Hk ecyH5avueY5so/YYuNpzmLP0VcDESKD5jr4Af2FHsvKGZAHNKhttaX6EEPf5/iJZ+yzypDdlthRL 5lDphz25eVPw26Qmt5MEm2dfMI2qqHzm0IlpRp7h5sibyRFkCSHLJqq6iZjUOFR3ApZTx0Fgxfmo w6uaZIv2q6dWIT8KqD+FIvWJ+VZm/kut1bgCN5HjSArC7294m4A6HeOr1IjtRhxhTsi9bPbxJp6M Elg8rclP4sQBwPDa2aR+KM4X0MGzYYr6g/gR5nQPTAE37m6KNuta3RTHvQRTXooGNJzR9Izn/ECE pGgvBOdRVcW/rn8o+yrxmHoF5nv6vwjrBcyo/CMPk4S7GX1kIgRi8VnEVgzOG60yZDrwwCGHL3Nw 85UcqDyVEmE1HlIPfHMuAlhdyEMj2F2HxUfSrU8d/ilqSKg8ZvosCFJWNjVsv5AdhN1jygPo13PS bLwi+rVV9uIdkx+zJ5a0mApo0uLiZg0LJLmPerp284qZle2Dxr5pJ6fdiosAO7QNJ8hb9YsRzAMB 2/JtcjwlAz8Rd3BOACs/z4B0yIYUEFivRoDKhmsKeZ1b9V8jKEPy60yO61c1rhbH6Hiw3ogRVJtY 5cLnTqOxdG0w/LIKV7SHIg5H7DRgbEUPdrhf9bxoIN0S8lTissrkAQuFX1OjxQXCZNbnJzJSIxMf zzUd1mhfWUKUMKRSUf4O7QFjCmhvr7dasV5Sh7WTCoaFzGROaddZARU1nXOQVJeU9prApdJGZu33 Dfv2xc1eFeCF8d8XLP2la+RVADGFaQzVC5ISo+qokL5hkDrK/JcDFDju99qfTJ8v+NIlQ0fLlInO Glczm21QWh6moSrY41eubDpJg8oJjZfWNBzocB3z05etYwroUWnF2lr5u9fqIEz/vl8pX3RVvvAC GlnM3W1jnJAbtEatHW7OIGio0fhoZdy93e/7xUeaDg4ZqRNN/EBTNkIIaA4sSevGh5lC5uUUk3BX Hb4A86C+eNbcGDZvDOpo6npvAZf3y/mCpE5E5YaoPAKUF/JDRTkkGC6Jh1AKSBLMuuwtljN9pGbO nGnC+fOmUy4hzypkdWuQZChnPjGdCX/1T4A01Wskb0mqw0rOiihQ1q7OLeSRkBrLpUHMLTr+b4nc DOBXaXICHHSq0qWsPt30zqHNJQcAhUJiitD0jkGWyJj4ww4peXv05k1qaxxAMpuzgrnMvih/tGCr ER5JNUTkr9xeBcdy0KcB+II9bxgB8KI2A1eH1Ndeg0/+Fh1KQXd6+xiHC/tqr9ZxJ0fH4gjEi5qW 5x9KFR79X9P4v7zC4/499YNcdybxSKFaIdK4MB9oD+vKXAVnRZYouRKdV7mGOS2iOmOae1yIHzkR UxyweUv+P6iU2xiLEkMrVNl1rspmLO9kU1ZhqQ3x/AzrKqX9j1JWsaYAUeIT6cYBKqOQTqVeqcEi BZMD9SJ4VQVX9FBVR/LCbLJCREFePOHj8QYPqfXHwVl5dJFl30GEyeaGVEwRjRzJR+Ugo84gnorj mC5uTZWEmBTUy/EFWXFKaH/RikFl+XZMKlqxtNQCOybfLKv9cGN9KRA14xIiaWtOxWthuXpNdz+9 GK5CJErZX/Qa14nPfaZmHqgTneX07R38LPCfnJ4zUGa6iS+VtIn33Uq5k4NaqcZbXLzP9bxwkLw8 K2tBY43vltUMIl6RVrEhI5pM+s573aOQqriEp/iaUS5haqSS4pN3FcrjUHWbiN+DCH3mrvUIamzg W0hgGeRtQxlEwPKmVAIsG6wxH/ry43A01GefJBsH3ctCgrqZ/hLak+p/5RbKKaxGCrCIkhop6L6h uRZ1tXh82GtBglBRLXk9o0Lmrvazl9izfzmHyY3JOJXxRpd4OHVM7YX8lt65/BFZ7jrVtp5TM0J5 l25WG6J1HUjYgz3rPG0eRJV4v7CEqtTWS66BXfxNk5Pljx+9iQkgYv6c7cKS+eP26WzUT72/P2W2 G5brLx1JS8y02Lh5an8FrfHpU2trlZMmdygL67L/vVst5QvtKkXRFy5DcrwQ3zIVO4+kd7ATy9+I BYBcNat1i/fZzkR8eAwdc/rzsCy+g84rhvf4ZC5M1tOzU+FEr4nn3Nq+TTh/WxDKC1nZ6xf0ZqN8 bsrFluuQBy8ML/hb0svZkDjGA43fOU5027i6ebkPl25CaJ0GnlhW2YijpRbMsL/xDXhvMc1gGMZv eogPqqS8RXxJxZO1NEeTOZSQOl9T7cBBVt6HpLeSZUtC+kT1KA7ol70J+XkQ/tmAgHcSUKD772KX 2VgyUeJsffyoBn6BQmkC31oXZwm4ZFz6RI4DME1x4iE4xqcO9dKo34AptTVIDVqj0WqAZvC/ehPE pc5VQOA8FYkUL/befcQpb0XiTHcGf8jJEMjauedCilhqHcUcbQ0bX6r0V+a1pt3Djwd2cPhdMAYX AEAUxBF+JiKHs6HeEZTjeIY9GD3kkMO93IjvxjzuW2Q+h6mXUAL+SRm17MnapuBOQCUrnr0+W9Ei Os6r8ZvB/GMJ/0bUJxEq60PrJAqx8BVbi3/uoMe2HiQyWI9kFHKJ+G+JgMO3wyVgbic6VsqbKhqp ci6im3lz9yThujhmcDSt+JiO+lrE/go0j68ShRCuD8tMEdG6KiIC/6osG38XYm96ePaWL8lfmlEs 2+NXwrX2EX4OBr/jcnr42YrTVHgLPGpiaAhIfzwn/0B1NlrtX/BCa143f+FYNkyezQoERFNr/SIC J34B5vCFUNxM5cTWOQEAZQfnHM+j4UQ0efc3RcWGRY6FYZinFPkZIPF9HGzQ6+/Gd7c8tMI/qYy/ EJ+xkFzK5PfnGulPFvLHmYDkAAQg51O9NxD3BADcGw0W/eF78g/y526zpn5dkg+fph8GY4jl8o6Q gPr1F/Kn51bjonUDkH96bjcvOjq/6jYvrnTyEzluHJMLcnxzDHeP9eOL4//kVwZc/XYsMHFaCMcE C+mCfz+BYgzIqbVjciyZkYTx5/rFz212HhTf8OCFehDFQuSEg+IHPUgisCSuHdePz6pH7isZKbJG lglqUm+H5lL2Bvj3iBSJX7Y7N+TiIv2SLZC3Mh4ZP+MjU1GN+z2WI/LTeFnhNPEzeW0QR7PVad/g 4Q1I0nEApTKl8b/xC/KwzjWDGzmWjqYt7bpxSxy6NsxdykPwxAWHVm918Lf1wWmDHya5+ID7fwNQ SwMEFAACAAgA74OePpHXiJgUDQAALUkAABQAAABpbmV0b3JncGVyc29uLnNjaGVtYdVce2/jNhL/ 2/4URBIgWSBxLPmdOxzgOt7WbZJN46S3xSLA0RJjsyuJiijF6376mxnqZSftZeu9uNqHLVPkcPib B2coUvtMBiJW0TwUkVZBQzsL4XN2csImUP4hml9TOTu6eT+ye4P+u/o+O/gQiuDifHh9xsLP81PP 5eGpFtET1DzVHg/dU0Pl9CXSx0/Malj9ht3oMLtpNU+b7VOrBZdnduus3Wefkyhm4y8hO6jv77Pb hdRsqaLPDL5DDrfUA8u6Z1P1EC95JNg/F3Ecnp2eLpfLhoK7yFIDej79VwOoIKGRCleRnC9iZg0G /RPsGYiLgtZ7lQQujyUwivWHnseovmaRoMG5Gakb4UodR3KWYG3GA5clWgCOTKskcgSVzGTAoxV7 UJGvj9lSxgumIvpWSYxUfOXKB+lQj8cMBwEw+TKOhctU4K0Y14wnUD2Sv0PRbMXiErtI4TqZedJh F9IRgRYZd0PmwFARphix88xdhI8/cenxmUesIrEHCdcXk9H4ajpOy5BCrMITTzwJj7kyEg5IMCUn 2NrAVQR8e7GIAhgEVF/BTxpaWRoZwySNlJnGIvY9lAzo0h9qGdw7F9DY1SwJVQA/GRQ8yECazh8A Zvax0Wk22TA2TAl2uwoN/HDvw+w3YJ6NPK41jIn9oDyXqNwFEsUCckzlNXFFEIMwgAd2dHcz0e/Y J2Sk2Rvc1/drR46KRKq9hjEGKE8T3+cFMsTJ0aD7jt2BtrCpMSPoh3SD5I8wPLUMabvT/SPSqJWj D9PJ1ZhGMgkQYRGnY00JIxHL7rXvGZDQYGc5EaDh8ChVinpqQX7igYi4l4AmwTg9F/UBGHMRGJCx ilwaBVXR2Zgy3VER0InEHIVP+spCjwPaAKxyJEeNpQEC6DJw5ZN0E+416jwTS4xSOWJ2w+o2+u1m A+zfavVazUYLL+u1q+HlmB0WXB/Wa+fj6Ygdptpwxp7EQjpemaMX+IFm45/vhheT218BAi0m8wDQ veSxs6jXpnffTW9vSuXTZIa6HMx1VuPXq9vhR3BOrUYX+Gojb+0uXFqdhmVb+LPDCF9XoCfyQWmu En8mEJ2RcgVJu7iH0C6BbcCFGQ/IZsJT0GGDGak4ABj3tIJyIIHcODEYfpD4Ai7ZkWjMG8fMslvt dzhi7oULvnFz+N3oFCq8ey3adob25hieYy4zqwDPUR4Wilqi2wOe5jyQv5MI3g58qUHaqyvuI2j/ XoggKwJyyBXwGIErEjoUoJweAJpxDH5VnHhgLEynxuuBCh0zCV4rNYiHxEO5zUC50VHCZQoD+GMW QJ/pXbQdEONUBuA/FBgLiAcFcAKUyBOhFDT0g+LXoNzBIfn4kiEeI7PcdcmfcY/lAqS2wA+QCoRw qaNzM0TDArDqoidEYwa9ID8fJlGocBZ4pR60c7srAfpcCcJIPIgogp42Bg+qvY48wg668gZ6ALUm V99fjE9+GV7cjY1WCD/01EqI3CCvUjvZtJtcqyN0X3IeGB+Ymegxgg+zMqrNDNjEGYOmOhcagFtc wIxINFPXh84n831lczC6MfdSl+q+Vi6tTCrrA3oumHQ8xGjZUoMcit0Z6ksC0jqorlQ6mVRgFBUX RQ3+FuaC8RL8vEsjgdzX4eyf1onwRj6QSHjEul7IEKcxI5Y0bgBKxjVICJ7BT+yNFDgFjhHk3jHb G6dE8NpENXh1C7Tp7heKJL099Iso4L274HOglsEeOlQoW5lemA9uMPPAr5Rfe9OqcNzPBUk0QJ1M LZrs0L9mWvg2U1zNoBjdKO//KZrrSEGcJqKh60uSQ1aA1zfCESHRkvFbycjqZkLKRv83FRAM+7dQ zK8XKlYlAWnQcoERBjoiH6+lz+cmmM4DwETjVIki/PF6/D17L0nGZAwOeMO5gDQ08nnMPv34fvL+ voEuU2FEsIAybJb3vBkuLPl6UJBmpJTSbeYQofQU5LUosgDDf5jhReBQwOMWGRZSkTFkkwmkCxSh esrBYP+5RJuNQQOiVBDswG42W00QLf5vdJuZTHO+nwuVGywIrcPXSMHuGynksckFIJdA67K5QB7i UI5SzkkOdSmgWUaYbKNHZjpUnwXOT15KKYvQi6CQ0AjSZJfiNUiaIggyVQCW6ZDUF4nPA4wAHeWH gE7aAhygmXt+MdlVHrNtiPDybnoLTQNKTkm3KOVey3mxZOigdZ5ko2YLwXEeNHldpgMSh2Oy2G7/ Pl2AAOUUX1LTPmNETIvHhPjf2yC7x/bO9nDiXqQKwJRZnShhw5kuT6cbA3p1zDPItOSZRP8sIH0m v1x6b+0UXop30IlNLyeX45GIYrPQg/o5ZNc/jab7PSOaltW5h4gEw51zHvNjDKojQXIBPYgpiUTL B6jToIiyAkms0poQVNMYfpCbeanP1P+D0CaxaY3pvg++00VLQepp0r/gT2Au7D9pzzRFIlUXOMuj KT7TcA+oZNUOjd4V2p0tPBW6gDU55V+pRDQmCxCyoaWUOAUPKINs9Ub70hcjHvKZ9ED70WxIvwm3 bqt1b3jHf0AG5jDpJz5ov3agV6gNGMqIERoQas4VKMvCB0EXBNcMkoxtjWvM1ky6Q57dJcYitBYd k32Vl/hgPkRoD1+SwD9MvUMUwUOxCHe82SEJp1Bv9YTz+4Im0ags0KIFqvn01AwxDL10MVHT+mW+ rhnA/HHG9lIu9hgEZIGGPjLDvvpwm+d0MIfoFQjrC2qcafDaCKtZnr03IXhuxqkVFLqfr0bpJAxV FKcDe9WE0ClMDulaNvzAC7Zv2eyTKboHaCnAQa/1YCZZxA/8oZl4QW+NeoJrN8FWvEJbC0xl48Fp uYGS+lI5mafREdLyYtUU142lI45TV14wWBJi4V/NmsLtplasaSFQ+l96aERg+inpHi4r5mSBTGr1 qObX7z+y6/O7fBQ8Ez7Z/i7UyV6PBs1gXpgMNgVWFgtgUWgBDPErVOnr/tDjhQSw89O8DnUpX5M2 8/3l+IfJlF2DYgO30xWIzqdIn6KeiVtcmbkLgnQc9w4XCq08500Zq8YCIWIaLt2RSmiWuuZaL3Fx mwrQkraE9/Xw5etrGTvfAMBXxMa9dLlFxuInsTqH+XD9V+pQTLaCTumcpszQPMqawwysY/BbHngw sOApNPwsVn8bpWzmoWJpSBXSzFQd/wbqmT8IWOPpTXQ0y6IfZKTjWwjzPDWndMU4SeMdaYqDiVRD kgzVWAz1GFUsZrEGezPFG+R4rXP9JoD1/tKkxKZx+rx8tACVEhjk/IxT/hOPJEagmlmocnazTg8N H60/FMFUvEDHxJp5LmjElN1gmed5E+n0crcAo6iOO3Ae7a0gtyES3A3g/WYBuF0lwFtbAd6KdgZ4 8Zj8sVUlwNtbAd6OF7sC3C4Ab1cJ8M5WgHd2B3irALxTmd0IzmN3K7y7u8O7XeDdrRDeva3w7u0K 7U6Bdq9K7qS/FdyCdlzuCPJuAXm/Qgo+2Arxwc4cyqAUogwqhLfV3Apwq7krxO1macq0mlWCfLtU 07J2p+RlyK0qQb5dqmnZu4O8FKhYdpUg3y7ZtFq7g7wUrVitKkG+Xbpp7S7fHJSiFatdJci3Szit 3WWcg14J8iqlnNZ2Oae1u6Rz0C9BXqWs09ou7bR6u4O8vDbeqxLk26WeVn93cXlpddyqUuppbZd7 WoPdQV5KPq0qZZ/2dtmnvcPss7RCblcl+wR0xlfnr3oo+rUPXF9+4joM9DI7HGa2AxXHcMsP+xl3 HNoVgDu8tnoWS1uEqVfr7dba8lCKV+YJrAHa/hZA228HdL8EtF0loFvfAujW2wE9KAHdqhLQ7W8B dPvt4tNmCejqJL7fwtV/9QxD+5FL70ug4/1ivQzEHeIbK4JYs1CoEDpfLhTt831+Xh/PUZbQM++w 8PE00So7MYCHPOIoceIkwkMv9DYF3IJMh5Aj+UR7kh8i5ZP2lKlxL+XInIIvnVqW9OYG22KfPsLn faOu6F0NRLz2sqbYDbvO4E+6J7U84uc6k593+rDGDsvqI6Hp3fWL3Jqbtzd3o9u7m+FFvXY5/JUd 1Ws1nrhSsQM2w0NcQusRADnHXd4HpRcuwI/Nk/XsABqXDllDlfXDvVCgdVAqprdYHOSnAOFyDjgH pjEQW4CIrhd4mueA0bXSMfeGrgty11BG54W4h5fFeTFsCLooPOHe3Uzglg+6SV8BnxMTvppJ6g1H GZpCaBSa5ixSyi8YFk4kYk6jT6Sbcls+poBNv3SazSSQj4koXrGBtDeP+VDlF0+vHJQ3zR/km6QP 8k2+xGppByP8Xt+h97wA+jqgGIvRl22+WuarjYMrbZd9V6/9hc13eCRFgEfNHWxqqeuFZVN10g3k In1vSf7akjmocXp+4E/896ssqFWyoHVOvt6Eal9tP4XsDPQGeQO8wd157NBnlz579Nmnz4Fp1TRf prVlmlumvWUI4Lb1Gl0YIpahYhkylqEDwX2tRoL9Srn+F1BLAQIUABQAAgAIAPmyjTwmALxUVhYA AOlMAAAOAAAAAAAAAAEAIAAAAAAAAABwcG9saWN5LnNjaGVtYVBLAQIUABQAAgAIAABuuT6Y4dX0 BwMAAAIHAAAKAAAAAAAAAAEAIAAAAIIWAABzbGFwZC5jb25mUEsBAhQAFAACAAgA74OePiINryvm EgAAalAAAAsAAAAAAAAAAQAgAAAAsRkAAGNvcmUuc2NoZW1hUEsBAhQAFAACAAgA74OePpHXiJgU DQAALUkAABQAAAAAAAAAAQAgAAAAwCwAAGluZXRvcmdwZXJzb24uc2NoZW1hUEsFBgAAAAAEAAQA 7wAAAAY6AAAAAA== ------_=_NextPart_001_01CC1AB8.7233BFF9--

1 0

(ITS#6952) Unable to get the Accout Locked message via Password Policy
by srinivas.kondamadugu＠mphasis.com 25 May '11

25 May '11

Full_Name: Srinivas Kondamadugu Version: 2.4.23 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.195.185.82) We installed and configured the OpenLDAP password policy and while testing with bind operation we are getting Error code as 49 (invalid credentials) but we need account locked messages to appeared. Even if we use ppolicy_use_lockout in ppolicy.la we are getting the same error code and when we view the admin console we are not able to see any operation attribute for the user w.r.t password policy etc., Configuration snnippet # required if the overlay is built dynamically moduleload ppolicy.la # invokes password policies for this DIT only overlay ppolicy # define the default policy ppolicy_default "uid=default,ou=pwpolicies,dc=mehisdomain,dc=com" ppolicy_use_lockout ppolicy_hash_cleartext

1 0

Re: (ITS#6915) memberof+accesslog duplicate reqStart
by hyc＠symas.com 24 May '11

24 May '11

ebackes(a)symas.com wrote: > The openldap-techincal traffic Michael mentioned is almost certainly the same issue. In our case, yes this could have appeared as early as 2.4.23. > > What I'm seeing now is that formerly memberof functioned with accesslog in > a delta-syncrepl type environment by having each stage of replication (master, hub, replica, etc) run the overlay to supply the changes. It seems like originally only the group change went through and the overlay relied on reqStart collisions to prevent its internal operations from reaching the replication log. > > So: the recent change that exposed this was something that changed the > order these things are applied and sent to accesslog. > > Changing memberof again to reveal only the group changes should probably a separate ITS, or perhaps a discussion (openldap-devel) on how we want it to work. As-is, the fix in git master breaks compatibility with configurations from prior releases. The breakage seems to go back to ITS#6329. The original design for memberOf was for the internal modifications to not be replicated. Instead, any replicas that wanted to maintain member information was expected to run an identical memberOf overlay configuration. The fact that memberOf didn't update the entryCSN on its internal modifications was intentional. This design constraint was broken by the fix to ITS#6329. The patch for #6329 and any ripple effect from it needs to be reverted. In general it's incorrect to replicate internal operations. The fanout from replicating every internal operation would be too large and the information content of what is being replicated is essentially nil. When the servers are configured identically they will maintain identical data by virtue of the overlays on each node performing the same internal operations in response to a given sequence of user operations. > Emily Backes > Symas - The LDAP Guys > ebackes(a)symas.com > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6951) pcache: valgrind reports some errors when bind-caching is enabled
by ralf＠OpenLDAP.org 24 May '11

24 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.222.177) Submitted by: ralf I get this when starting a bind-caching slapo-pcache setup under valgrind: ==18290== Invalid write of size 1 ==18290== at 0x59628F: ftemp_attrs (pcache.c:490) ==18290== by 0x5A29E0: pc_cf_gen (pcache.c:4199) [..] ==18290== Address 0x768dcc6 is 0 bytes after a block of size 6 alloc'd ==18290== at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18290== by 0x509CC85: ber_memalloc_x (memory.c:228) ==18290== by 0x46B958: ch_malloc (ch_malloc.c:54) ==18290== by 0x596206: ftemp_attrs (pcache.c:448) [..] ==18290== ==18290== Invalid write of size 1 ==18290== at 0x5A3153: pc_cf_gen (pcache.c:4281) [..] ==18290== Address 0x768e437 is 0 bytes after a block of size 7 alloc'd ==18290== at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18290== by 0x509CC85: ber_memalloc_x (memory.c:228) ==18290== by 0x46B958: ch_malloc (ch_malloc.c:54) ==18290== by 0x5A30D5: pc_cf_gen (pcache.c:4270) [..] A fix is on the way to HEAD.

1 0

Re: (ITS#6920) OpenLDAP 2.4.25 / Berkeley DB 4.8.30 Solaris 10 x86 slapd hangs
by fumiyas＠osstech.jp 24 May '11

24 May '11

At Thu, 28 Apr 2011 18:05:43 GMT, mslby(a)deshaw.com wrote: > My company uses OpenLDAP 2.4.25 with Berkeley DB 4.8.30 compiled on Solaris > 10 x86 using Sun Studio. OpenLDAP is used as the backend for generic naming > services (passwd, group, netgroup etc?) as well as holding mail routing and > some custom data. We have master and slave servers and are using syncrepl > refresh and persist. Are you using Solaris nss_ldap and ldap_cachemgr(1M) on your Solaris 10 with OpenLDAP slapd? If so, Solaris libldap.so breaks your slapd process as the following scenario: (1) slapd calls some name service functions, e.g. getpwnam(3C). (2) Solaris nss_ldap (/usr/lib/nss_ldap.so.1) is loaded. (3) Solaris libldap.so (/usr/lib/libldap.so.5) is loaded. (4) Solaris libldap.so overrides ldap_*() and ber_*() functions in slapd (or OpenLDAP libldap_r.so and liblber.so). (5) OpenLDAP calls ldap_*() and ber_*() functions that are belong to Solaris libldap.so, not OpenLDAP's one. See also: http://www.openldap.org/lists/openldap-technical/200902/msg00000.html https://bugzilla.mozilla.org/show_bug.cgi?id=292127 http://bugzilla.padl.com/show_bug.cgi?id=203 -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- Personal Home: http://www.SFO.jp/blog/ > Lately we have been experiencing hangs with slapd and I cannot figure out > what the cause is. Things will be humming along and then slapd will simply > stop accepting connections and answering any requests for reads/writes. We > have set the loglevel to 256 and there is nothing in the logs that > indicates what the issue it. At the time that the process goes catatonic all > syslogs from slapd stop > > I have not found a way to reproduce this on demand. > > Today we have had three hangs and the truss ouput is exactly the same on > all process. Once the slapd process gets in this state a simple kill does > not work. The syslog always says that slapd is waiting for tasks to > complete but this never happens. I need to kill -9 the pid. > > I am going to include all of the debug info that I have collected and > hopefully someone will have some idea what is going on. I also have a gcore > of the process if anyone wants and info from that > > All and any help is greatly appreciated

1 0

Re: (ITS#6950) pcache crashing when '+' or '*' is used in attrsets
by Ralf Haferkamp 24 May '11

24 May '11

'1.1' is also causing a crash (on shutdown)

1 0

(ITS#6950) pcache crashing when '+' or '*' is used in attrsets
by ralf＠OpenLDAP.org 24 May '11

24 May '11

Full_Name: Ralf Haferkamp Version: 2.4.25/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.222.177) Submitted by: ralf The pcache overlay crashes slapd when using * or + in a pcacheAttrset. It seems the problem was introduced with the recent changes to support caching of undefined attributes. Fix is on the way.

1 0

Re: (ITS#6941
by rhafer＠suse.de 24 May '11

24 May '11

> Some how this got duplicated from ITS#6940, please close. Done.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 24 May '11

24 May '11

On 05/23/2011 10:15 PM, Tim.Mooney(a)ndsu.edu wrote: > Thank you Pierangelo. We've been running with that patch since last > Friday without problems, so I'm comfortable with the fix. > > If you can do so without having to spend much time on it, could you give > a brief overview of what you believe might be involved in implementing the > longer fix? I won't make any promises, but if you give me a hint at what > would be involved, I might be able to contribute the code to skip mapping > when not needed. That seems like it would be very beneficial. I don't think it's worth the effort, because mapping and rewriting are somehow tightly joined, so as soon as the overlay is loaded it is nearly always worth to scan all data to check whether intervention is needed. Further optimization would make the code even more hairy without significant improvements. p.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 23 May '11

23 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, Pierangelo...: > On 05/20/2011 10:21 PM, Tim.Mooney(a)ndsu.edu wrote: >> In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, >> masarati(a)aero.po...: >> >>> The bug is caused by the fact that "mapping" is always on, and slapo-rwm >>> checks whether there is anything it can/need to do about special >>> attributes, and it (incorrectly) assumed attributes have an equality rule. >>> It has nothing to do with the fact that you defined no rules for search >>> or so. >>> >>> The quick fix would be to check whether sat_equality is NULL; the >>> (possibly) long fix would be to entirely skip mapping when not needed. >> >> My apologies for the delay in responding. >> >> I've uploaded a patch, >> >> TimMooney-110520.patch >> >> to incoming. It tests that sat_equality is not NULL before dereferencing. >> >> Is this essentially what you had in mind as a fix? > > Yes. Fixed in HEAD. Thanks, p. Thank you Pierangelo. We've been running with that patch since last Friday without problems, so I'm comfortable with the fix. If you can do so without having to spend much time on it, could you give a brief overview of what you believe might be involved in implementing the longer fix? I won't make any promises, but if you give me a hint at what would be involved, I might be able to contribute the code to skip mapping when not needed. That seems like it would be very beneficial. Tim -- Tim Mooney Tim.Mooney(a)ndsu.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164

1 0

(ITS#6949) OpenLDAP Logging
by andrew.stringer＠igt.com 23 May '11

23 May '11

Full_Name: Andrew Stringer Version: @(#) $OpenLDAP: slapd 2.3.43 OS: Red Hat 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.205.160.142) Software Enhancement Requests Hi, we are currently rebuilding our LDAP tree using vendor current version of software, including openLDAP. I don't have much LDAP experience, so may be there is already a way to do this, but I have not found it despite several trips to Google. etc.. Logging in openldap seems to be all via syslog and controlled by a value made up by adding the code for a particular log entry of interest, all of which are sent to syslog under one facility number. I feel that logging could be improved by allowing logging similar to how BIND's named does it, namely having different log files for queries, normal operational logs and zone transfers (or in LDAP's case, replications). This would make it much easier to monitor the activity of the server without having to grep out unwanted information to see the required detail. Regards, Andrew.

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by masarati＠aero.polimi.it 23 May '11

23 May '11

On 05/20/2011 10:21 PM, Tim.Mooney(a)ndsu.edu wrote: > In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, masarati(a)aero.po...: > >> The bug is caused by the fact that "mapping" is always on, and slapo-rwm >> checks whether there is anything it can/need to do about special >> attributes, and it (incorrectly) assumed attributes have an equality rule. >> It has nothing to do with the fact that you defined no rules for search >> or so. >> >> The quick fix would be to check whether sat_equality is NULL; the >> (possibly) long fix would be to entirely skip mapping when not needed. > > My apologies for the delay in responding. > > I've uploaded a patch, > > TimMooney-110520.patch > > to incoming. It tests that sat_equality is not NULL before dereferencing. > > Is this essentially what you had in mind as a fix? Yes. Fixed in HEAD. Thanks, p.

1 0

RE: (ITS#6944) Add option to limit or remove operation list cache
by jorge.perez.burgos＠ericsson.com 22 May '11

22 May '11

Hello Quanah, Our slapd uses back-meta to communicate to other slapds. We have to fulfill some requirements related with bandwith with network latencies and packet loss between slapds, to fulfill such requirements we need to increase these threads. Best Regards -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: viernes, 20 de mayo de 2011 19:01 To: Jorge Perez Burgos; openldap-its(a)openldap.org Subject: Re: (ITS#6944) Add option to limit or remove operation list cache --On May 19, 2011 8:03:00 AM +0000 jorge.perez.burgos(a)ericsson.com wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.21 > OS: SLES 10 SP3 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.235.15.243) > > > Our slapd uses 256 threads Why do you have 256 thread set? Do you have a 64-core box? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6948) slaptest fails a converting a working cn=config from a .conf with a pcache configuration
by tgates81＠gmail.com 22 May '11

22 May '11

Full_Name: Tyler Gates Version: 2.4.25 OS: Ubuntu 10.04 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.184.61.44) I've been fighting with a strange issue related to a backend database using a pcache configuration since upgrading from 2.4.24 to 2.4.25. Assuming there was just something wrong with my cn=config I decided to start back fresh using slapd.conf instead. Once I got the config working just fine I used slaptest to convert the config to a new cn=config. Unfortunately when I tried using -F cn=config instead of my -f slapd.conf, slapd failed with the same old message: May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup: warning, database 0 (hdb) has no suffix May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one: starting "(unknown)" May 22 09:15:58 directory-proxy2 slapd[25055]: hdb_db_open: need suffix. May 22 09:15:58 directory-proxy2 slapd[25055]: backend_startup_one (type=hdb, suffix="(null)"): bi_db_open failed! (-1) May 22 09:15:58 directory-proxy2 slapd[25055]: slapd shutdown: initiated The backend database has never required me specify a suffix since it is already specified in the ldap overlay and when I try to add it in I get slapd trying to open the database twice which results in the second instance having access issues thus rendering all of the database inaccessible to queries. I'm assuming there has been a configuration change in cn=config for this particular layout but slaptest has not been updated. Below is a copy of the flat file I used that worked fine but failed once converted to cn=config using slaptest -f slapd.conf -F /etc/ldap/slapd.d/ root@directory-proxy:~# grep "^[^#]" /etc/ldap/slapd.conf.back_ldap_ppcache include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/sudo.schema include /etc/ldap/schema/autofs.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/qmail.schema include /etc/ldap/schema/puppet.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_ldap moduleload back_hdb moduleload pcache moduleload ppolicy TLSCertificateFile /etc/ldap/ssl/slapd.crt TLSCertificateKeyFile /etc/ldap/ssl/slapd.key TLSCACertificateFile /etc/ssl/certs/ca.castlebranch.com.crt loglevel -1 allow bind_anon_dn database config rootdn cn=admin,cn=config rootpw secret access to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break database ldap suffix "dc=domain,dc=com" rootdn "cn=Manager,dc=domain,dc=com" rootpw secret uri "ldaps://directory1.domain.com ldaps://directory2.domain.com" overlay pcache proxycache hdb 100000 3 1000 100 proxyAttrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description memberUid uniqueMember objectClass proxyAttrset 1 cn automountInformation proxyAttrset 2 cn mail proxyTemplate (&(objectClass=)(|(memberUid=)(uniqueMember=))) 0 1800 proxyTemplate (&(objectClass=)(uid=)) 0 1800 proxyTemplate (&(objectClass=)(cn=)) 0 1800 proxyTemplate (&(objectClass=)) 0 1800 proxyTemplate (objectClass=) 0 1800 proxyTemplate (&(objectClass=)(memberUid=)) 0 1800 900 proxyTemplate (&(objectClass=)(uniqueMember=)) 0 1800 900 proxyTemplate (&(objectClass=)(uidNumber=)) 0 1800 proxyTemplate (&(objectClass=)(gidNumber=)) 0 1800 proxyTemplate (&(objectClass=)(|(cn=)(gidNumber=))) 1 3600 600 proxyTemplate (&(objectClass=)(|(cn=)(cn=))) 1 3600 600 proxyTemplate (&(objectClass=)(|(cn=)(cn=)(cn=))) 1 3600 600 proxyTemplate (|(cn=)(mail=)(sn=)) 2 7200 directory /var/lib/ldap cachesize 1000 idletimeout 600 idlcachesize 3000 index objectClass eq index cn,mail,surname,givenname eq,subinitial index uidNumber,gidNumber,memberuid,member,uniqueMember eq index uid eq,subinitial index nisMapName,automountInformation eq index userPassword,homeDirectory,loginShell,gecos,description eq index pcacheQueryID eq

1 0

Re: (ITS#6943) segfault in rwmmap in 2.4.25
by Tim.Mooney＠ndsu.edu 20 May '11

20 May '11

In regard to: Re: (ITS#6943) segfault in rwmmap in 2.4.25, masarati(a)aero.po...: > The bug is caused by the fact that "mapping" is always on, and slapo-rwm > checks whether there is anything it can/need to do about special > attributes, and it (incorrectly) assumed attributes have an equality rule. > It has nothing to do with the fact that you defined no rules for search > or so. > > The quick fix would be to check whether sat_equality is NULL; the > (possibly) long fix would be to entirely skip mapping when not needed. My apologies for the delay in responding. I've uploaded a patch, TimMooney-110520.patch to incoming. It tests that sat_equality is not NULL before dereferencing. Is this essentially what you had in mind as a fix? Tim

1 0

Re: (ITS#6944) Add option to limit or remove operation list cache
by quanah＠zimbra.com 20 May '11

20 May '11

--On May 19, 2011 8:03:00 AM +0000 jorge.perez.burgos(a)ericsson.com wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.21 > OS: SLES 10 SP3 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.235.15.243) > > > Our slapd uses 256 threads Why do you have 256 thread set? Do you have a 64-core box? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6947) ldapadd crashes with LDIFs with invalid line termination
by jvcelak＠redhat.com 19 May '11

19 May '11

Full_Name: Jan Vcelak Version: 2.4.25 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20110519-ldif-countlines.patch Submission from: (NULL) (209.132.186.34) Hello, adding entries to LDAP database from file using ldapadd tool causes memory corruption error, when the last line of the input file is not terminated by '\n' character. The entries are added correctly. All version since 2.4.23 are affected. $ cat >/tmp/input.ldif << EOF > dn: cn=A,dc=my-domain,dc=com > objectClass: inetOrgPerson > objectClass: organizationalPerson > objectClass: person > objectClass: top > cn: A > sn: A > uid: A > mail: A(a)example.com > EOF $ wc -c /tmp/input.ldif 166 /tmp/input.ldif $ truncate -s 165 /tmp/input.ldif $ hexdump -c /tmp/input.ldif 0000000 d n : c n = A , d c = m y - d 0000010 o m a i n , d c = c o m \n o b j 0000020 e c t C l a s s : i n e t O r 0000030 g P e r s o n \n o b j e c t C l 0000040 a s s : o r g a n i z a t i o 0000050 n a l P e r s o n \n o b j e c t 0000060 C l a s s : p e r s o n \n o b 0000070 j e c t C l a s s : t o p \n c 0000080 n : A \n s n : A \n u i d : 0000090 A \n m a i l : A @ e x a m p l 00000a0 e . c o m 00000a5 $ ldapadd -H ldap:// -D cn=Manager,dc=my-domain,dc=com -x -w password -f /tmp/input.ldif adding new entry "cn=A,dc=my-domain,dc=com" *** glibc detected *** ldapadd: free(): invalid pointer: 0x0000000001c435c8 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3626e76d63] ldapadd[0x404505] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3626e1ee5d] ldapadd[0x4037e9] ======= Memory map: ======== ... I am attaching proposed patch, which fixes this issue. Thank you Jan

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs