From nkinder at redhat.com Mon Aug 3 16:06:56 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 03 Aug 2009 09:06:56 -0700 Subject: [389-devel] Please Review: (514955) Don't replicate DNA generation mod In-Reply-To: <4A736D27.5050503@redhat.com> References: <4A736D27.5050503@redhat.com> Message-ID: <4A770B20.7090103@redhat.com> On 07/31/2009 03:16 PM, Nathan Kinder wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=514955 The previous patch did not handle all cases. This new patch takes a different approach than the previous patch. Instead of trimming the mod that triggered generation, we leave it alone and make DNA check subsequent mods before commiting to generating a new value. This is easily done by just unsetting the generate flag if we find a subsequent mod for the same attribute in the same operation. > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Bug-514955-Make-DNA-handle-multiple-mods.patch URL: From nhosoi at redhat.com Mon Aug 3 16:17:44 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 03 Aug 2009 09:17:44 -0700 Subject: [389-devel] Please Review: (514955) Don't replicate DNA generation mod In-Reply-To: <4A770B20.7090103@redhat.com> References: <4A736D27.5050503@redhat.com> <4A770B20.7090103@redhat.com> Message-ID: <4A770DA8.7030702@redhat.com> On 08/03/2009 09:06 AM, Nathan Kinder wrote: > On 07/31/2009 03:16 PM, Nathan Kinder wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=514955 > The previous patch did not handle all cases. This new patch takes a > different approach > than the previous patch. Instead of trimming the mod that triggered > generation, we leave > it alone and make DNA check subsequent mods before commiting to > generating a new > value. This is easily done by just unsetting the generate flag if we > find a subsequent > mod for the same attribute in the same operation. Looks good. --noriko >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Mon Aug 3 17:05:30 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 03 Aug 2009 10:05:30 -0700 Subject: [389-devel] Please Review: (514955) Don't replicate DNA generation mod In-Reply-To: <4A770DA8.7030702@redhat.com> References: <4A736D27.5050503@redhat.com> <4A770B20.7090103@redhat.com> <4A770DA8.7030702@redhat.com> Message-ID: <4A7718DA.1060408@redhat.com> On 08/03/2009 09:17 AM, Noriko Hosoi wrote: > On 08/03/2009 09:06 AM, Nathan Kinder wrote: >> On 07/31/2009 03:16 PM, Nathan Kinder wrote: >>> https://bugzilla.redhat.com/show_bug.cgi?id=514955 >> The previous patch did not handle all cases. This new patch takes a >> different approach >> than the previous patch. Instead of trimming the mod that triggered >> generation, we leave >> it alone and make DNA check subsequent mods before commiting to >> generating a new >> value. This is easily done by just unsetting the generate flag if we >> find a subsequent >> mod for the same attribute in the same operation. > Looks good. > --noriko Pushed to master. Thanks for the review! >>> ------------------------------------------------------------------------ >>> >>> -- >>> 389-devel mailing list >>> 389-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhosoi at redhat.com Tue Aug 4 18:10:35 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 04 Aug 2009 11:10:35 -0700 Subject: [389-devel] Please review: [Bug 513916] Server doesn't ignore paged control, if page size and server's estimate of total no of entries are same In-Reply-To: <200908041743.n74Hhc56010479@bz-web1.app.phx.redhat.com> References: <200908041743.n74Hhc56010479@bz-web1.app.phx.redhat.com> Message-ID: <4A78799B.7040108@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=513916 *Bug 513916* -Server doesn't ignore paged control, if page size and server's estimate of total no of entries are same Description of problem: simple paged control which is equal to page size returned is not returning to the shell prompt. Paged control prompt even though there are no entries to be returned. How reproducible: Consistently Steps to Reproduce: 1. Add few entries to Directory server. 2. Write a simple paged search with page control which is equal to the no of entries returned by server. 3. Observe the prompt. For Eg: no of entries returned for the search is 6. Write a paged request as below. ./ldapsearch.pl -x -pg 6 "cn=test*" "cn sn" -S "sn" Actual results: Server doesn't ignore the paged control even the request can be satisfied in a single page. Expected results: Server should ignore the paged control if the page size is equal to paged control. [Files] ldap/servers/plugins/chainingdb/cb.h ldap/servers/plugins/chainingdb/cb_init.c ldap/servers/plugins/chainingdb/cb_search.c ldap/servers/slapd/back-ldbm/idl_common.c ldap/servers/slapd/back-ldbm/idl_new.c ldap/servers/slapd/back-ldbm/init.c ldap/servers/slapd/back-ldbm/ldbm_search.c ldap/servers/slapd/back-ldbm/proto-back-ldbm.h ldap/servers/slapd/backend.c ldap/servers/slapd/backend_manager.c ldap/servers/slapd/dl.c ldap/servers/slapd/dse.c ldap/servers/slapd/opshared.c ldap/servers/slapd/pblock.c ldap/servers/slapd/proto-slap.h ldap/servers/slapd/slap.h ldap/servers/slapd/slapi-private.h [Fix Description] The code processing search results were returning the PAGE END without knowing there are more entries to return or not. To learn it, introduced "read ahead" one entry when it comes to the PAGE END. If there are more entries, the code undo the read ahead, which prompts for the next page on the client side. If there is no more entries, it returns the status SEARCH END instead of PAGE END. In addition to the read ahead implementation to fix the bug 513916, * supporting Simple Paged Results for chaining backend is added. * fixed a bug in idl_new_fetch (idl_new.c) -- idlistscanlimit was not checked when the cursor comes to the end of an index file. [Proposed Fix] Created an attachment (id=356215) --> (https://bugzilla.redhat.com/attachment.cgi?id=356215) git patch file -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Aug 4 18:51:17 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 04 Aug 2009 11:51:17 -0700 Subject: [389-devel] Please review (corrected): [Bug 513916] Server doesn't ignore paged control, if page size and server's estimate of total no of entries are same In-Reply-To: <4A78799B.7040108@redhat.com> References: <200908041743.n74Hhc56010479@bz-web1.app.phx.redhat.com> <4A78799B.7040108@redhat.com> Message-ID: <4A788325.7090207@redhat.com> Sorry, this is the right patch: [Proposed Fix] --> (https://bugzilla.redhat.com/attachment.cgi?id=356229) git patch file (a correct one...) On 08/04/2009 11:10 AM, Noriko Hosoi wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=513916 > > *Bug 513916* -Server doesn't ignore paged control, if page size and server's estimate of total no of entries are same > > Description of problem: simple paged control which is equal to page size > returned is not returning to the shell prompt. Paged control prompt even though > there are no entries to be returned. > > How reproducible: Consistently > > Steps to Reproduce: > 1. Add few entries to Directory server. > 2. Write a simple paged search with page control which is equal to the no of > entries returned by server. > 3. Observe the prompt. > > For Eg: no of entries returned for the search is 6. Write a paged request as > below. > ./ldapsearch.pl -x -pg 6 "cn=test*" "cn sn" -S "sn" > > > Actual results: Server doesn't ignore the paged control even the request can be > satisfied in a single page. > > > Expected results: Server should ignore the paged control if the page size is > equal to paged control. > > > [Files] > ldap/servers/plugins/chainingdb/cb.h > ldap/servers/plugins/chainingdb/cb_init.c > ldap/servers/plugins/chainingdb/cb_search.c > ldap/servers/slapd/back-ldbm/idl_common.c > ldap/servers/slapd/back-ldbm/idl_new.c > ldap/servers/slapd/back-ldbm/init.c > ldap/servers/slapd/back-ldbm/ldbm_search.c > ldap/servers/slapd/back-ldbm/proto-back-ldbm.h > ldap/servers/slapd/backend.c > ldap/servers/slapd/backend_manager.c > ldap/servers/slapd/dl.c > ldap/servers/slapd/dse.c > ldap/servers/slapd/opshared.c > ldap/servers/slapd/pblock.c > ldap/servers/slapd/proto-slap.h > ldap/servers/slapd/slap.h > ldap/servers/slapd/slapi-private.h > > [Fix Description] > The code processing search results were returning the PAGE END without knowing > there are more entries to return or not. To learn it, introduced "read ahead" > one entry when it comes to the PAGE END. If there are more entries, the code > undo the read ahead, which prompts for the next page on the client side. > If there is no more entries, it returns the status SEARCH END instead of PAGE > END. > > In addition to the read ahead implementation to fix the bug 513916, > * supporting Simple Paged Results for chaining backend is added. > * fixed a bug in idl_new_fetch (idl_new.c) -- idlistscanlimit was not checked > when the cursor comes to the end of an index file. > > [Proposed Fix] > Created an attachment (id=356215) > --> (https://bugzilla.redhat.com/attachment.cgi?id=356215) > git patch file > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Tue Aug 4 19:52:26 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 04 Aug 2009 12:52:26 -0700 Subject: [389-devel] Please review (corrected): [Bug 513916] Server doesn't ignore paged control, if page size and server's estimate of total no of entries are same In-Reply-To: <4A788325.7090207@redhat.com> References: <200908041743.n74Hhc56010479@bz-web1.app.phx.redhat.com> <4A78799B.7040108@redhat.com> <4A788325.7090207@redhat.com> Message-ID: <4A78917A.9090809@redhat.com> On 08/04/2009 11:51 AM, Noriko Hosoi wrote: > Sorry, this is the right patch: > [Proposed Fix] > --> (https://bugzilla.redhat.com/attachment.cgi?id=356229) > git patch file (a correct one...) > ack. > > On 08/04/2009 11:10 AM, Noriko Hosoi wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=513916 >> >> *Bug 513916* -Server doesn't ignore paged control, if page size and server's estimate of total no of entries are same >> >> Description of problem: simple paged control which is equal to page size >> returned is not returning to the shell prompt. Paged control prompt even though >> there are no entries to be returned. >> >> How reproducible: Consistently >> >> Steps to Reproduce: >> 1. Add few entries to Directory server. >> 2. Write a simple paged search with page control which is equal to the no of >> entries returned by server. >> 3. Observe the prompt. >> >> For Eg: no of entries returned for the search is 6. Write a paged request as >> below. >> ./ldapsearch.pl -x -pg 6 "cn=test*" "cn sn" -S "sn" >> >> >> Actual results: Server doesn't ignore the paged control even the request can be >> satisfied in a single page. >> >> >> Expected results: Server should ignore the paged control if the page size is >> equal to paged control. >> >> >> [Files] >> ldap/servers/plugins/chainingdb/cb.h >> ldap/servers/plugins/chainingdb/cb_init.c >> ldap/servers/plugins/chainingdb/cb_search.c >> ldap/servers/slapd/back-ldbm/idl_common.c >> ldap/servers/slapd/back-ldbm/idl_new.c >> ldap/servers/slapd/back-ldbm/init.c >> ldap/servers/slapd/back-ldbm/ldbm_search.c >> ldap/servers/slapd/back-ldbm/proto-back-ldbm.h >> ldap/servers/slapd/backend.c >> ldap/servers/slapd/backend_manager.c >> ldap/servers/slapd/dl.c >> ldap/servers/slapd/dse.c >> ldap/servers/slapd/opshared.c >> ldap/servers/slapd/pblock.c >> ldap/servers/slapd/proto-slap.h >> ldap/servers/slapd/slap.h >> ldap/servers/slapd/slapi-private.h >> >> [Fix Description] >> The code processing search results were returning the PAGE END without knowing >> there are more entries to return or not. To learn it, introduced "read ahead" >> one entry when it comes to the PAGE END. If there are more entries, the code >> undo the read ahead, which prompts for the next page on the client side. >> If there is no more entries, it returns the status SEARCH END instead of PAGE >> END. >> >> In addition to the read ahead implementation to fix the bug 513916, >> * supporting Simple Paged Results for chaining backend is added. >> * fixed a bug in idl_new_fetch (idl_new.c) -- idlistscanlimit was not checked >> when the cursor comes to the end of an index file. >> >> [Proposed Fix] >> Created an attachment (id=356215) >> --> (https://bugzilla.redhat.com/attachment.cgi?id=356215) >> git patch file >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhosoi at redhat.com Tue Aug 4 20:05:03 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 04 Aug 2009 13:05:03 -0700 Subject: [389-devel] Commit: [Bug 513916] Server doesn't ignore paged control, if page size and server's estimate of total no of entries are same In-Reply-To: <4A78917A.9090809@redhat.com> References: <200908041743.n74Hhc56010479@bz-web1.app.phx.redhat.com> <4A78799B.7040108@redhat.com> <4A788325.7090207@redhat.com> <4A78917A.9090809@redhat.com> Message-ID: <4A78946F.9090308@redhat.com> On 08/04/2009 12:52 PM, Nathan Kinder wrote: > On 08/04/2009 11:51 AM, Noriko Hosoi wrote: >> Sorry, this is the right patch: >> [Proposed Fix] >> --> (https://bugzilla.redhat.com/attachment.cgi?id=356229) >> git patch file (a correct one...) >> > ack. Thank you!! Pushed to master. >> >> On 08/04/2009 11:10 AM, Noriko Hosoi wrote: >>> https://bugzilla.redhat.com/show_bug.cgi?id=513916 >>> >>> *Bug 513916* -Server doesn't ignore paged control, if page size and server's estimate of total no of entries are same >>> >>> Description of problem: simple paged control which is equal to page size >>> returned is not returning to the shell prompt. Paged control prompt even though >>> there are no entries to be returned. >>> >>> How reproducible: Consistently >>> >>> Steps to Reproduce: >>> 1. Add few entries to Directory server. >>> 2. Write a simple paged search with page control which is equal to the no of >>> entries returned by server. >>> 3. Observe the prompt. >>> >>> For Eg: no of entries returned for the search is 6. Write a paged request as >>> below. >>> ./ldapsearch.pl -x -pg 6 "cn=test*" "cn sn" -S "sn" >>> >>> >>> Actual results: Server doesn't ignore the paged control even the request can be >>> satisfied in a single page. >>> >>> >>> Expected results: Server should ignore the paged control if the page size is >>> equal to paged control. >>> >>> >>> [Files] >>> ldap/servers/plugins/chainingdb/cb.h >>> ldap/servers/plugins/chainingdb/cb_init.c >>> ldap/servers/plugins/chainingdb/cb_search.c >>> ldap/servers/slapd/back-ldbm/idl_common.c >>> ldap/servers/slapd/back-ldbm/idl_new.c >>> ldap/servers/slapd/back-ldbm/init.c >>> ldap/servers/slapd/back-ldbm/ldbm_search.c >>> ldap/servers/slapd/back-ldbm/proto-back-ldbm.h >>> ldap/servers/slapd/backend.c >>> ldap/servers/slapd/backend_manager.c >>> ldap/servers/slapd/dl.c >>> ldap/servers/slapd/dse.c >>> ldap/servers/slapd/opshared.c >>> ldap/servers/slapd/pblock.c >>> ldap/servers/slapd/proto-slap.h >>> ldap/servers/slapd/slap.h >>> ldap/servers/slapd/slapi-private.h >>> >>> [Fix Description] >>> The code processing search results were returning the PAGE END without knowing >>> there are more entries to return or not. To learn it, introduced "read ahead" >>> one entry when it comes to the PAGE END. If there are more entries, the code >>> undo the read ahead, which prompts for the next page on the client side. >>> If there is no more entries, it returns the status SEARCH END instead of PAGE >>> END. >>> >>> In addition to the read ahead implementation to fix the bug 513916, >>> * supporting Simple Paged Results for chaining backend is added. >>> * fixed a bug in idl_new_fetch (idl_new.c) -- idlistscanlimit was not checked >>> when the cursor comes to the end of an index file. >>> >>> [Proposed Fix] >>> Created an attachment (id=356215) >>> --> (https://bugzilla.redhat.com/attachment.cgi?id=356215) >>> git patch file >>> >>> ------------------------------------------------------------------------ >>> >>> -- >>> 389-devel mailing list >>> 389-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Fri Aug 7 18:58:55 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 07 Aug 2009 11:58:55 -0700 Subject: [389-devel] Please review: [Bug 506786] Index maintenance mechanism causes wrong search results when modifying attributes with subtypes In-Reply-To: <200908071851.n77IpFhP004312@bz-web2.app.phx.redhat.com> References: <200908071851.n77IpFhP004312@bz-web2.app.phx.redhat.com> Message-ID: <4A7C796F.2020702@redhat.com> Summary: Index maintenance mechanism causes wrong search results when modifying attributes with subtypes https://bugzilla.redhat.com/show_bug.cgi?id=506786 [Problem Description] When adding a value to an attribute with subtype indexed on equality and then deleting this attribute subtype the index is not maintained correctly which results in wrong search results afterwards. After stopping the server and reindexing with db2index everything works correctly again. The unindexed and substring searches do not seem to be concerned. [Fix Description] When checking the same value exists in the entry, instead of using the type to be modified, pass the basetype. It covers the both cases removing the attribute with subtype as well as with no subtype (basetype). [Proposed Fix] Created an attachment (id=356696) --> (https://bugzilla.redhat.com/attachment.cgi?id=356696) git patch file (index.c) Thanks to Nathan for his idea to fix this problem. I verified your suggestion worked on the case that Andrey reported. From nhosoi at redhat.com Tue Aug 11 00:56:07 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 10 Aug 2009 17:56:07 -0700 Subject: [389-devel] Please review (revised): [Bug 506786] Index maintenance mechanism causes wrong search results when modifying attributes with subtypes In-Reply-To: <4A7C796F.2020702@redhat.com> References: <200908071851.n77IpFhP004312@bz-web2.app.phx.redhat.com> <4A7C796F.2020702@redhat.com> Message-ID: <4A80C1A7.8050508@redhat.com> Summary: Index maintenance mechanism causes wrong search results when modifying attributes with subtypes https://bugzilla.redhat.com/show_bug.cgi?id=506786 There was a not-working case found in my previous proposal. The problem is if these attribute value pairs exist in an entry: mail: abc mail;en: abc mail;fr: xyz removing mail=abc or mail;en=abc, should not remove =abc from the mail.db#. My previous fix worked only when removing "mail;en=abc", but not when removing "mail=abc". [Problem Description] When adding a value to an attribute with subtype indexed on equality and then deleting this attribute subtype the index is not maintained correctly which results in wrong search results afterwards. After stopping the server and reindexing with db2index everything works correctly again. The unindexed and substring searches do not seem to be concerned. [Fix Description] When there are identical attribute value pairs except subtypes exist in an entry, if one of the pairs are deleted, it should not affect the index the attribute value is the key. e.g., mail: abc mail;en: abc mail;fr: xyz removing mail=abc or mail;en=abc, should not remove =abc from the mail.db#. This fix uses the value array evals to determine if the equality key in the index should be deleted or not. The value array evals stores the values of the attribute in the entry after the deletion is done. If evals is empty, it means the to-be-deleted attribute value pair is the only pair in the entry. Thus, the equality key can be removed fom the index. If evals has values, then the to-be-deleted attribute (curr_attr, which was retrieved from the old entry) value needs to be checked if it's in evals or not. If it is in evals, the equality key is still used by other pair(s). So, leave it. Otherwise, the key can be removed. In the above example, let's assume removing mail=abc. evals holds {"abc", "xyz"}. curr_attr abc is in evals, thus =abc will not be removed. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-506786-Index-maintenance-mechanism-causes-wrong-sea.patch Type: text/x-patch Size: 4373 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Aug 11 14:16:29 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 11 Aug 2009 08:16:29 -0600 Subject: [389-devel] Please review (revised): [Bug 506786] Index maintenance mechanism causes wrong search results when modifying attributes with subtypes In-Reply-To: <4A80C1A7.8050508@redhat.com> References: <200908071851.n77IpFhP004312@bz-web2.app.phx.redhat.com> <4A7C796F.2020702@redhat.com> <4A80C1A7.8050508@redhat.com> Message-ID: <4A817D3D.30207@redhat.com> Noriko Hosoi wrote: > Summary: Index maintenance mechanism causes wrong search results when > modifying attributes with subtypes > > https://bugzilla.redhat.com/show_bug.cgi?id=506786 > > There was a not-working case found in my previous proposal. > > The problem is if these attribute value pairs exist in an entry: > mail: abc > mail;en: abc > mail;fr: xyz > removing mail=abc or mail;en=abc, should not remove =abc from the > mail.db#. My previous fix worked only when removing "mail;en=abc", > but not when removing "mail=abc". > > [Problem Description] > > When adding a value to an attribute with subtype indexed on equality > and then > deleting this attribute subtype the index is not maintained correctly > which > results in wrong search results afterwards. After stopping the server and > reindexing with db2index everything works correctly again. The > unindexed and > substring searches do not seem to be concerned. > > [Fix Description] > When there are identical attribute value pairs except subtypes exist > in an entry, if one of the pairs are deleted, it should not affect the > index the attribute value is the key. > > e.g., > mail: abc > mail;en: abc > mail;fr: xyz > > removing mail=abc or mail;en=abc, should not remove =abc from the > mail.db#. > > This fix uses the value array evals to determine if the equality key > in the index should be deleted or not. The value array evals stores > the values of the attribute in the entry after the deletion is done. > If evals is empty, it means the to-be-deleted attribute value pair is > the only pair in the entry. Thus, the equality key can be removed fom > the index. > > If evals has values, then the to-be-deleted attribute (curr_attr, > which was retrieved from the old entry) value needs to be checked if > it's in evals or not. If it is in evals, the equality key is still > used by other pair(s). So, leave it. Otherwise, the key can be > removed. > > In the above example, let's assume removing mail=abc. evals holds > {"abc", "xyz"}. curr_attr abc is in evals, thus =abc will not be > removed. ack > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Aug 11 20:42:32 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 11 Aug 2009 14:42:32 -0600 Subject: [389-devel] Please review: change default branding to 389 - remove lite code Message-ID: <4A81D7B8.7020502@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Change-default-branding-to-389-remove-lite-code.patch Type: text/x-patch Size: 131182 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Tue Aug 11 21:14:58 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 11 Aug 2009 14:14:58 -0700 Subject: [389-devel] Please review: change default branding to 389 - remove lite code In-Reply-To: <4A81D7B8.7020502@redhat.com> References: <4A81D7B8.7020502@redhat.com> Message-ID: <4A81DF52.4020104@redhat.com> ack. On 08/11/2009 01:42 PM, Rich Megginson wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Tue Aug 11 21:18:42 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 11 Aug 2009 15:18:42 -0600 Subject: [389-devel] Please review: change default branding to 389 - remove lite code In-Reply-To: <4A81DF52.4020104@redhat.com> References: <4A81D7B8.7020502@redhat.com> <4A81DF52.4020104@redhat.com> Message-ID: <4A81E032.9020807@redhat.com> Nathan Kinder wrote: > ack. Thanks - pushed to master > > On 08/11/2009 01:42 PM, Rich Megginson wrote: >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Aug 12 15:04:59 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 12 Aug 2009 09:04:59 -0600 Subject: [389-devel] Please review: fix some pcre build issues Message-ID: <4A82DA1B.6050307@redhat.com> Some minor issues encountered when building pcre on different platforms. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-pcre-build-issues.patch Type: text/x-patch Size: 4300 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Wed Aug 12 15:07:35 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 12 Aug 2009 08:07:35 -0700 Subject: [389-devel] Please review: fix some pcre build issues In-Reply-To: <4A82DA1B.6050307@redhat.com> References: <4A82DA1B.6050307@redhat.com> Message-ID: <4A82DAB7.70003@redhat.com> On 08/12/2009 08:04 AM, Rich Megginson wrote: > Some minor issues encountered when building pcre on different platforms. ack. > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Aug 12 15:11:04 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 12 Aug 2009 09:11:04 -0600 Subject: [389-devel] Please review: fix some pcre build issues In-Reply-To: <4A82DAB7.70003@redhat.com> References: <4A82DA1B.6050307@redhat.com> <4A82DAB7.70003@redhat.com> Message-ID: <4A82DB88.6000401@redhat.com> Nathan Kinder wrote: > On 08/12/2009 08:04 AM, Rich Megginson wrote: >> Some minor issues encountered when building pcre on different platforms. > ack. Thanks - pushed >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From yersinia.spiros at gmail.com Wed Aug 12 15:24:05 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Wed, 12 Aug 2009 17:24:05 +0200 Subject: [389-devel] Please review: fix some pcre build issues In-Reply-To: <4A82DB88.6000401@redhat.com> References: <4A82DA1B.6050307@redhat.com> <4A82DAB7.70003@redhat.com> <4A82DB88.6000401@redhat.com> Message-ID: On Wed, Aug 12, 2009 at 5:11 PM, Rich Megginson wrote: > Nathan Kinder wrote: > >> On 08/12/2009 08:04 AM, Rich Megginson wrote: >> >>> Some minor issues encountered when building pcre on different platforms. >>> >> ack. >> > Thanks - pushed > >> ------------------------------------------------------------------------ >>> >>> -- >>> 389-devel mailing list >>> 389-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >>> >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> >> > > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > Attention to rely on pkg-config for pcre for cross-platoform, upstream pcre.pc is wrong for linux because it include in Libs -L${libdir} : $cat /usr/lib64/pkgconfig/libpcre.pc # Package Information for pkg-config prefix=/usr exec_prefix=/usr libdir=/usr/lib64 includedir=/usr/include Name: libpcre Description: PCRE - Perl compatible regular expressions C library Version: 7.8 Libs: -L${libdir} -lpcre Cflags: -I${includedir} BUT, not every Linux distro as Fedora and RHEL include a local patch a pkgconfig for this problem e.g. with the previous pcre.pc $pkg-config --libs libpcre -lpcre Look at this ref for more detail https://bugzilla.novell.com/show_bug.cgi?id=529921 hth -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Thu Aug 13 23:30:52 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 13 Aug 2009 16:30:52 -0700 Subject: [389-devel] Please Review: Add centralized start/stop/restart scripts. Message-ID: <4A84A22C.6040406@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Add-centralized-start-stop-restart-scipts.patch URL: From nkinder at redhat.com Fri Aug 14 15:44:49 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 14 Aug 2009 08:44:49 -0700 Subject: [389-devel] Please Review: Add centralized start/stop/restart scripts. In-Reply-To: <4A84A22C.6040406@redhat.com> References: <4A84A22C.6040406@redhat.com> Message-ID: <4A858671.6010306@redhat.com> Pushed to master. Thanks to Rich for his review. He spotted a few paths that should have been macros in the new stop and restart script. This patch fixes those issues and includes the generated Makefile.in changes. On 08/13/2009 04:30 PM, Nathan Kinder wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Add-centralized-start-stop-restart-scipts.patch URL: From rmeggins at redhat.com Thu Aug 20 17:38:52 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 20 Aug 2009 11:38:52 -0600 Subject: [389-devel] Please review: Bug 518520 - pre hashed salted passwords do not work Message-ID: <4A8D8A2C.2040608@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=518520 Resolves: bug 518520 Bug Description: pre hashed salted passwords do not work Reviewed by: ??? Files: see diff Branch: HEAD and 1.2 Fix Description: Pre-hashed passwords may not use the standard internal salt length. The old ldif base64 decode function would return the number of bytes in the decoded string - the new NSPR function does not. We can't use strlen on the decoded value since it is binary and may contain nulls. The solution is to use a function to calculate exactly how many bytes the encode string will have when decoded, taking into account padding. Since we know exactly how many bytes are decoded, and we know exactly how many bytes of that decoded value are the hash, the remainder must be the salt, however many bytes that is. I tested this code with salt lengths from 1 to 99. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=358138&action=diff From nkinder at redhat.com Thu Aug 20 17:55:58 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 20 Aug 2009 10:55:58 -0700 Subject: [389-devel] Please review: Bug 518520 - pre hashed salted passwords do not work In-Reply-To: <4A8D8A2C.2040608@redhat.com> References: <4A8D8A2C.2040608@redhat.com> Message-ID: <4A8D8E2E.2030801@redhat.com> On 08/20/2009 10:38 AM, Rich Megginson wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=518520 > Resolves: bug 518520 > Bug Description: pre hashed salted passwords do not work > Reviewed by: ??? > Files: see diff > Branch: HEAD and 1.2 > Fix Description: Pre-hashed passwords may not use the standard > internal salt length. The old > ldif base64 decode function would return the number of bytes in the > decoded > string - the new NSPR function does not. We can't use strlen on > the decoded > value since it is binary and may contain nulls. The solution is to > use a > function to calculate exactly how many bytes the encode string will > have > when decoded, taking into account padding. Since we know exactly > how many > bytes are decoded, and we know exactly how many bytes of that > decoded value > are the hash, the remainder must be the salt, however many bytes > that is. > I tested this code with salt lengths from 1 to 99. > Platforms tested: RHEL5 x86_64 > Flag Day: no > Doc impact: no > https://bugzilla.redhat.com/attachment.cgi?id=358138&action=diff ack > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel From rmeggins at redhat.com Fri Aug 21 22:49:09 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 21 Aug 2009 16:49:09 -0600 Subject: [389-devel] Please review: Bug 518544 - large entries cause server SASL responses to fail Message-ID: <4A8F2465.3030302@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=518544 Resolves: bug 518544 Bug Description: large entries cause server SASL responses to fail Reviewed by: ??? Files: see diff Branch: HEAD and 1.2 Fix Description: The SASL server code was broken when we switched over to use NSPR I/O for the SASL IO layer. If the entire encrypted buffer could not be sent to the client, the server was just failing. Instead, the server must keep track of how many encrypted bytes were sent. If all of the encrypted bytes could not be sent, we must return the appropriate error to the caller to let them know the operation would block. The caller in this case is the write_function() which does a poll() to see if the socket is available for writing again, then will attempt the send again. I also cleaned up usage of the various Debug macros. Finally, I discovered that the sasl init code was calling config_get_localhost() before that value could be set. In most cases, it is ok, because it will fall back to the default hostname from the system. However, if for some reason you want to use a different localhost, it will fail. Now it will be in the bootstrap config code. Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=358289&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Aug 21 23:59:34 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 21 Aug 2009 17:59:34 -0600 Subject: [389-devel] Re: [Bug 518544] large entries cause server SASL responses to fail In-Reply-To: <200908212307.n7LN7BPE028676@bz-web2.app.phx.redhat.com> References: <200908212307.n7LN7BPE028676@bz-web2.app.phx.redhat.com> Message-ID: <4A8F34E6.9040802@redhat.com> Thanks pushed to master and 1.2 branch bugzilla at redhat.com wrote: > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug. > > > https://bugzilla.redhat.com/show_bug.cgi?id=518544 > > > Noriko Hosoi changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |nhosoi at redhat.com > Devel Whiteboard| |comment#8.review+nhosoi > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Aug 24 16:47:05 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 24 Aug 2009 10:47:05 -0600 Subject: [389-devel] Please review: Bug 518418 - Package rename shuts down server, results in unconfigured package Message-ID: <4A92C409.5030404@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=518418 Resolves: bug 518418 Bug Description: Package rename shuts down server, results in unconfigured package Reviewed by: ??? Files: see diff Branch: HEAD and 1.2 Fix Description: In the %pre section, check to see if fedora-ds-base exists. If so, save the run level configuration, restore it in the %posttrans section, and start the server. Note that this hack is only needed for Fedora 10 and Fedora 11, so we can get rid of the hack once Fedora 11 becomes obsolete. Platforms tested: Fedora 11 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=358482&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Aug 24 23:24:57 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 24 Aug 2009 17:24:57 -0600 Subject: [389-devel] Please review:try again - Bug 518418 - Package rename shuts down server, results in unconfigured package Message-ID: <4A932149.5000208@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=518418 Resolves: bug 518418 Bug Description: Package rename shuts down server, results in unconfigured package Reviewed by: ??? Files: see diff Branch: HEAD and 1.2 Fix Description: It occurred to me that using tar and untarring the file is a tremendous security hole, with no obvious way to secure it. Therefore, I'm scrapping that solution, and going with a solution that uses the built-in lua interpreter. This also allows me to save the information in a global variable in the %pre section that I can access in the %posttrans section, which should be very secure. Platforms tested: Fedora 11 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=358509&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Aug 25 17:48:20 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 25 Aug 2009 11:48:20 -0600 Subject: [389-devel] Please review: Bug 519065 - Fails to start if attrcrypt can't unwrap keys Message-ID: <4A9423E4.3000708@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=519065 Resolves: bug 519065 Bug Description: Fails to start if attrcrypt can't unwrap keys Reviewed by: ??? Files: see diff Branch: HEAD and 1.2 Fix Description: https://bugzilla.redhat.com/show_bug.cgi?id=519065 Platforms tested: RHEL5 x86_64 Flag Day: no Doc impact: no https://bugzilla.redhat.com/attachment.cgi?id=358610&action=diff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Aug 25 19:34:58 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 25 Aug 2009 13:34:58 -0600 Subject: [389-devel] Please review: Bug 519065 - Fails to start if attrcrypt can't unwrap keys In-Reply-To: <4A9423E4.3000708@redhat.com> References: <4A9423E4.3000708@redhat.com> Message-ID: <4A943CE2.60005@redhat.com> pushed to master and 1.2 Rich Megginson wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=519065 > Resolves: bug 519065 > Bug Description: Fails to start if attrcrypt can't unwrap keys > Reviewed by: ??? > Files: see diff > Branch: HEAD and 1.2 > Fix Description: https://bugzilla.redhat.com/show_bug.cgi?id=519065 > Platforms tested: RHEL5 x86_64 > Flag Day: no > Doc impact: no > https://bugzilla.redhat.com/attachment.cgi?id=358610&action=diff > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Aug 25 22:32:49 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 25 Aug 2009 15:32:49 -0700 Subject: [389-devel] Please review: Plugin Default Config Entry Message-ID: <4A946691.9030905@redhat.com> Plugin Default Config Entry Design doc: http://directory.fedoraproject.org/wiki/Entry_USN#Plugin_Default_Config_Entry New slapi APIs in libslapd: int slapi_set_plugin_default_config(char *type, char *attr); Description: Set given "type: attr" to the plugin default config entry (cn=plugin default config,cn=config). Parameters: type - Attribute type to add to the default config entry attr - Attribute value to add to the default config entry Return Value: 0 if the operation was successful non-0 if the operation was not successful int slapi_get_plugin_default_config(char *type, char ***attrs); Description: Get attribute values of given type from the plugin default config entry (cn=plugin default config,cn=config). Parameters: type - Attribute type to get from the default config entry attrs - Pointer to the string array to store the values of the attribute Return Value: 0 if the operation was successful non-0 if the operation was not successful warning: Caller is responsible to free attrs by slapi_ch_array_free Changes in the Replication plugin: 1) Functions to set replicated attributes agmt_set_replicated_attributes_from_attr and agmt_set_replicated_attributes_from_entry call _agmt_set_default_fractional_attrs to sets the default excluded attribute list from the plugin default config entry before setting them from each replication agreement. To support it, agmt_parse_excluded_attrs_config_attr is changed to be re-entrant. 2) Fixed a minor memory leak in the fractional attributes (ra->frac_attrs). 3) Added a check for the duplicated fractional attributes. Changes in the USN plugin: usn_start calls slapi_get_plugin_default_config to check if "entryusn" is in the EXCLUDE list of the value of nsds5ReplicatedAttributeList in the plugin default config entry or not. If it does not exist, the function adds it. Note: If the nsds5ReplicatedAttributeList value exists and "entryusn" is not in the EXCLUDE list, we have to append it to the list instead of replacing it. Thanks, --noriko -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Plugin-Default-Config-Entry.patch Type: text/x-patch Size: 23905 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Aug 26 16:13:13 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 26 Aug 2009 10:13:13 -0600 Subject: [389-devel] Please review: Plugin Default Config Entry In-Reply-To: <4A946691.9030905@redhat.com> References: <4A946691.9030905@redhat.com> Message-ID: <4A955F19.8080708@redhat.com> Noriko Hosoi wrote: > Plugin Default Config Entry > > Design doc: > http://directory.fedoraproject.org/wiki/Entry_USN#Plugin_Default_Config_Entry > > > New slapi APIs in libslapd: > int slapi_set_plugin_default_config(char *type, char *attr); > Description: Set given "type: attr" to the plugin default config entry > (cn=plugin default config,cn=config). > Parameters: type - Attribute type to add to the default config entry > attr - Attribute value to add to the default config entry > Return Value: 0 if the operation was successful > non-0 if the operation was not successful > > int slapi_get_plugin_default_config(char *type, char ***attrs); > Description: Get attribute values of given type from the plugin default > config entry (cn=plugin default config,cn=config). > Parameters: type - Attribute type to get from the default config entry > attrs - Pointer to the string array to store the values of > the attribute > Return Value: 0 if the operation was successful > non-0 if the operation was not successful > warning: Caller is responsible to free attrs by slapi_ch_array_free > > Changes in the Replication plugin: > 1) Functions to set replicated attributes > agmt_set_replicated_attributes_from_attr and > agmt_set_replicated_attributes_from_entry > call _agmt_set_default_fractional_attrs to sets the default excluded > attribute list from the plugin default config entry before setting > them from each replication agreement. > To support it, agmt_parse_excluded_attrs_config_attr is changed to be > re-entrant. > 2) Fixed a minor memory leak in the fractional attributes > (ra->frac_attrs). > 3) Added a check for the duplicated fractional attributes. > > Changes in the USN plugin: > usn_start calls slapi_get_plugin_default_config to check if "entryusn" is > in the EXCLUDE list of the value of nsds5ReplicatedAttributeList in the > plugin default config entry or not. If it does not exist, the function > adds it. Note: If the nsds5ReplicatedAttributeList value exists and > "entryusn" is not in the EXCLUDE list, we have to append it to the list > instead of replacing it. > > Thanks, > --noriko > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel About this code: if (new_attrs) { - *attrs = new_attrs; + charray_merge_nodup(attrs, new_attrs, 0); + slapi_ch_free((void **)&new_attrs); } the 0 flag to charray_merge_nodup() means "do not copy" - so the strings in new_attrs will be moved to attrs, if they are not duplicates. If they are duplicates, they will not be moved - how will they be freed? There's no way for the caller of charray_merge_nodup to know which strings were moved and which were not (except by comparing pointers in attrs with new_attrs). + int i; + const char *val = slapi_value_get_string(sval); + for (i = slapi_attr_first_value(attr, &sval); I don't think you should be calling slapi_value_get_string() here since sval is not initialized yet. I think slapi_set_plugin_default_config() should always to a modify/add, and just ignore "type or value exists" errors. Or support single valued attributes only. Or allow the user to specify to add or replace in the case of a multi-valued attribute. What if the user modifies the list directly over LDAP or by editing dse.ldif? An internal call to set the value will wipe out their settings. Also, there is a reference to frational attr in the slapi_set_plugin_default_config() code. I think slapi_set_plugin_default_config() will leak the pblock used for the initial search if rc != LDAP_SUCCESS or entries is NULL or empty. slapi_get_plugin_default_config() - since you are assuming that the values of the requested attribute are all null terminated strings (since you are using slapi_value_get_string()), you could just use slapi_entry_attr_get_charray() to get all of the values as a char **. Why does slapi_set_plugin_default_config() take a char * argument i.e. setting an attribute with a single string value, but slapi_get_plugin_default_config() returns multiple values from a single attribute? I'm not sure what the code in usn_start() is doing. Is nsds5ReplicatedAttributeList multi-valued? If so, each char * in char **old_frac_attrs will be a full attribute list description "(objectclass=*) $ EXCLUDE ...". Then I'm not sure what the code that adds the entryusn attribute to the default excluded list is doing - will it add entryusn to only the first value of nsds5ReplicatedAttributeList? And wipe out the other values? I think that's what will happen, since there is a break in the for loop if token == NULL - it will skip old_frac_attrs[1] etc. Also the call to charray_add - the token argument is not a malloced string, so that will cause problems when slapi_ch_array_free() is called. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Wed Aug 26 23:50:23 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 26 Aug 2009 16:50:23 -0700 Subject: [389-devel] Please review (revised): Plugin Default Config Entry In-Reply-To: <4A955F19.8080708@redhat.com> References: <4A946691.9030905@redhat.com> <4A955F19.8080708@redhat.com> Message-ID: <4A95CA3F.3080404@redhat.com> Thanks a lot, Rich! I revised my proposal based upon your suggestions. Some comments are in-line... --noriko On 08/26/2009 09:13 AM, Rich Megginson wrote: [...] > About this code: > if (new_attrs) > { > - *attrs = new_attrs; > + charray_merge_nodup(attrs, new_attrs, 0); > + slapi_ch_free((void **)&new_attrs); > } > > the 0 flag to charray_merge_nodup() means "do not copy" - so the > strings in new_attrs will be moved to attrs, if they are not > duplicates. If they are duplicates, they will not be moved - how will > they be freed? There's no way for the caller of charray_merge_nodup > to know which strings were moved and which were not (except by > comparing pointers in attrs with new_attrs). I wanted to avoid malloc/free as much as possible, but it looks I cannot... :( Changing it as follows: if (new_attrs) { charray_merge_nodup(attrs, new_attrs, 1); slapi_ch_array_free(new_attrs); } > > + int i; > + const char *val = slapi_value_get_string(sval); > + for (i = slapi_attr_first_value(attr, &sval); > > I don't think you should be calling slapi_value_get_string() here > since sval is not initialized yet. Thanks for finding it out! My copy & paste error... :( Changing it as follows: int i; const char *val = NULL; for (i = slapi_attr_first_value(attr, &sval); > > I think slapi_set_plugin_default_config() should always to a > modify/add, and just ignore "type or value exists" errors. Or support > single valued attributes only. Or allow the user to specify to add or > replace in the case of a multi-valued attribute. I was thinking the value is preferably single, but I wanted to support multiple values if set (e.g., by manually adding dse.ldif as you mentioned). That made the code uglier. I changed slapi_set_plugin_default_config simply adds the given "attr: value" pair to the plugin default config entry instead of replacing the existing pair(s) with it. > What if the user modifies the list directly over LDAP or by editing > dse.ldif? An internal call to set the value will wipe out their > settings. > Also, there is a reference to frational attr in the > slapi_set_plugin_default_config() code. Thanks! I removed it... :p > > I think slapi_set_plugin_default_config() will leak the pblock used > for the initial search if rc != LDAP_SUCCESS or entries is NULL or empty. I think it's taken care here.... Valgrind shows no leak in slapi_set_plugin_default_config in both cases entries exist or don't exist. 2911 } else { /* cn=plugin default config does not exist. Let's add it. */ 2912 LDAPMod *mods[3]; 2913 LDAPMod mod[2]; 2914 const char *objectclass[3]; 2915 char *attrlist[2]; 2916 *2917 slapi_free_search_results_internal(&pb); 2918 pblock_done(&pb);* > > slapi_get_plugin_default_config() - since you are assuming that the > values of the requested attribute are all null terminated strings > (since you are using slapi_value_get_string()), you could just use > slapi_entry_attr_get_charray() to get all of the values as a char **. Thanks! This is what I needed... > > Why does slapi_set_plugin_default_config() take a char * argument i.e. > setting an attribute with a single string value, but > slapi_get_plugin_default_config() returns multiple values from a > single attribute? > > I'm not sure what the code in usn_start() is doing. Is > nsds5ReplicatedAttributeList multi-valued? If so, each char * in char > **old_frac_attrs will be a full attribute list description > "(objectclass=*) $ EXCLUDE ...". Then I'm not sure what the code that > adds the entryusn attribute to the default excluded list is doing - > will it add entryusn to only the first value of > nsds5ReplicatedAttributeList? And wipe out the other values? I think > that's what will happen, since there is a break in the for loop if > token == NULL - it will skip old_frac_attrs[1] etc. Also the call to > charray_add - the token argument is not a malloced string, so that > will cause problems when slapi_ch_array_free() is called. > I cleaned up the code. It just adds the attribute value as follows. /* add nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn * to cn=plugin default config,cn=config */ rc = slapi_set_plugin_default_config("nsds5ReplicatedAttributeList", "(objectclass=*) $ EXCLUDE entryusn"); Sorry about the previous code I wiped out. I wanted to do this... Let's assume we found exisiting nsds5ReplicatedAttributeList lines: nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type1 type 2 I wanted to convert them in to one line: nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 type1 type 2 entryusn Instead, I changed to just add nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn to the entry. So, it'll end up like this: nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type1 type 2 nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Plugin-Default-Config-Entry.patch Type: text/x-patch Size: 22232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Aug 28 14:25:13 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 28 Aug 2009 08:25:13 -0600 Subject: [389-devel] Please review (revised): Plugin Default Config Entry In-Reply-To: <4A95CA3F.3080404@redhat.com> References: <4A946691.9030905@redhat.com> <4A955F19.8080708@redhat.com> <4A95CA3F.3080404@redhat.com> Message-ID: <4A97E8C9.4020302@redhat.com> Noriko Hosoi wrote: > Thanks a lot, Rich! I revised my proposal based upon your > suggestions. Some comments are in-line... > --noriko > > On 08/26/2009 09:13 AM, Rich Megginson wrote: > [...] >> About this code: >> if (new_attrs) >> { >> - *attrs = new_attrs; >> + charray_merge_nodup(attrs, new_attrs, 0); >> + slapi_ch_free((void **)&new_attrs); >> } >> >> the 0 flag to charray_merge_nodup() means "do not copy" - so the >> strings in new_attrs will be moved to attrs, if they are not >> duplicates. If they are duplicates, they will not be moved - how >> will they be freed? There's no way for the caller of >> charray_merge_nodup to know which strings were moved and which were >> not (except by comparing pointers in attrs with new_attrs). > I wanted to avoid malloc/free as much as possible, but it looks I > cannot... :( Changing it as follows: > if (new_attrs) > { > charray_merge_nodup(attrs, new_attrs, 1); > slapi_ch_array_free(new_attrs); > } > >> >> + int i; >> + const char *val = slapi_value_get_string(sval); >> + for (i = slapi_attr_first_value(attr, &sval); >> >> I don't think you should be calling slapi_value_get_string() here >> since sval is not initialized yet. > Thanks for finding it out! My copy & paste error... :( Changing it > as follows: > int i; > const char *val = NULL; > for (i = slapi_attr_first_value(attr, &sval); >> >> I think slapi_set_plugin_default_config() should always to a >> modify/add, and just ignore "type or value exists" errors. Or >> support single valued attributes only. Or allow the user to specify >> to add or replace in the case of a multi-valued attribute. > I was thinking the value is preferably single, but I wanted to support > multiple values if set (e.g., by manually adding dse.ldif as you > mentioned). That made the code uglier. I changed > slapi_set_plugin_default_config simply adds the given "attr: value" > pair to the plugin default config entry instead of replacing the > existing pair(s) with it. >> What if the user modifies the list directly over LDAP or by editing >> dse.ldif? An internal call to set the value will wipe out their >> settings. > >> Also, there is a reference to frational attr in the >> slapi_set_plugin_default_config() code. > Thanks! I removed it... :p >> >> I think slapi_set_plugin_default_config() will leak the pblock used >> for the initial search if rc != LDAP_SUCCESS or entries is NULL or >> empty. > I think it's taken care here.... Valgrind shows no leak in > slapi_set_plugin_default_config in both cases entries exist or don't > exist. > 2911 } else { /* cn=plugin default config does not exist. Let's > add it. */ > 2912 LDAPMod *mods[3]; > 2913 LDAPMod mod[2]; > 2914 const char *objectclass[3]; > 2915 char *attrlist[2]; > 2916 > *2917 slapi_free_search_results_internal(&pb); > 2918 pblock_done(&pb);* > >> >> slapi_get_plugin_default_config() - since you are assuming that the >> values of the requested attribute are all null terminated strings >> (since you are using slapi_value_get_string()), you could just use >> slapi_entry_attr_get_charray() to get all of the values as a char **. > Thanks! This is what I needed... >> >> Why does slapi_set_plugin_default_config() take a char * argument >> i.e. setting an attribute with a single string value, but >> slapi_get_plugin_default_config() returns multiple values from a >> single attribute? >> >> I'm not sure what the code in usn_start() is doing. Is >> nsds5ReplicatedAttributeList multi-valued? If so, each char * in >> char **old_frac_attrs will be a full attribute list description >> "(objectclass=*) $ EXCLUDE ...". Then I'm not sure what the code >> that adds the entryusn attribute to the default excluded list is >> doing - will it add entryusn to only the first value of >> nsds5ReplicatedAttributeList? And wipe out the other values? I >> think that's what will happen, since there is a break in the for loop >> if token == NULL - it will skip old_frac_attrs[1] etc. Also the call >> to charray_add - the token argument is not a malloced string, so that >> will cause problems when slapi_ch_array_free() is called. >> > I cleaned up the code. It just adds the attribute value as follows. > /* add nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE > entryusn > * to cn=plugin default config,cn=config */ > rc = slapi_set_plugin_default_config("nsds5ReplicatedAttributeList", > "(objectclass=*) $ EXCLUDE > entryusn"); > > Sorry about the previous code I wiped out. I wanted to do this... > Let's assume we found exisiting nsds5ReplicatedAttributeList lines: > nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 > nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type1 type 2 > I wanted to convert them in to one line: > nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 type1 > type 2 entryusn > > Instead, I changed to just add nsds5ReplicatedAttributeList: > (objectclass=*) $ EXCLUDE entryusn to the entry. So, it'll end up > like this: > nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 > nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type1 type 2 > nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn Ok - will the replication code be able to handle multiple values of nsds5ReplicatedAttributeList? > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Fri Aug 28 15:18:01 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 28 Aug 2009 08:18:01 -0700 Subject: [389-devel] Please review (revised): Plugin Default Config Entry In-Reply-To: <4A97E8C9.4020302@redhat.com> References: <4A946691.9030905@redhat.com> <4A955F19.8080708@redhat.com> <4A95CA3F.3080404@redhat.com> <4A97E8C9.4020302@redhat.com> Message-ID: <4A97F529.2050004@redhat.com> On 08/28/2009 07:25 AM, Rich Megginson wrote: > Noriko Hosoi wrote: >> Thanks a lot, Rich! I revised my proposal based upon your >> suggestions. Some comments are in-line... >> --noriko >> >> On 08/26/2009 09:13 AM, Rich Megginson wrote: >> [...] >>> About this code: >>> if (new_attrs) >>> { >>> - *attrs = new_attrs; >>> + charray_merge_nodup(attrs, new_attrs, 0); >>> + slapi_ch_free((void **)&new_attrs); >>> } >>> >>> the 0 flag to charray_merge_nodup() means "do not copy" - so the >>> strings in new_attrs will be moved to attrs, if they are not >>> duplicates. If they are duplicates, they will not be moved - how >>> will they be freed? There's no way for the caller of >>> charray_merge_nodup to know which strings were moved and which were >>> not (except by comparing pointers in attrs with new_attrs). >> I wanted to avoid malloc/free as much as possible, but it looks I >> cannot... :( Changing it as follows: >> if (new_attrs) >> { >> charray_merge_nodup(attrs, new_attrs, 1); >> slapi_ch_array_free(new_attrs); >> } >> >>> >>> + int i; >>> + const char *val = slapi_value_get_string(sval); >>> + for (i = slapi_attr_first_value(attr, &sval); >>> >>> I don't think you should be calling slapi_value_get_string() here >>> since sval is not initialized yet. >> Thanks for finding it out! My copy & paste error... :( Changing it >> as follows: >> int i; >> const char *val = NULL; >> for (i = slapi_attr_first_value(attr, &sval); >>> >>> I think slapi_set_plugin_default_config() should always to a >>> modify/add, and just ignore "type or value exists" errors. Or >>> support single valued attributes only. Or allow the user to specify >>> to add or replace in the case of a multi-valued attribute. >> I was thinking the value is preferably single, but I wanted to >> support multiple values if set (e.g., by manually adding dse.ldif as >> you mentioned). That made the code uglier. I changed >> slapi_set_plugin_default_config simply adds the given "attr: value" >> pair to the plugin default config entry instead of replacing the >> existing pair(s) with it. >>> What if the user modifies the list directly over LDAP or by editing >>> dse.ldif? An internal call to set the value will wipe out their >>> settings. >> >>> Also, there is a reference to frational attr in the >>> slapi_set_plugin_default_config() code. >> Thanks! I removed it... :p >>> >>> I think slapi_set_plugin_default_config() will leak the pblock used >>> for the initial search if rc != LDAP_SUCCESS or entries is NULL or >>> empty. >> I think it's taken care here.... Valgrind shows no leak in >> slapi_set_plugin_default_config in both cases entries exist or don't >> exist. >> 2911 } else { /* cn=plugin default config does not exist. Let's >> add it. */ >> 2912 LDAPMod *mods[3]; >> 2913 LDAPMod mod[2]; >> 2914 const char *objectclass[3]; >> 2915 char *attrlist[2]; >> 2916 *2917 slapi_free_search_results_internal(&pb); >> 2918 pblock_done(&pb);* >> >>> >>> slapi_get_plugin_default_config() - since you are assuming that the >>> values of the requested attribute are all null terminated strings >>> (since you are using slapi_value_get_string()), you could just use >>> slapi_entry_attr_get_charray() to get all of the values as a char **. >> Thanks! This is what I needed... >>> >>> Why does slapi_set_plugin_default_config() take a char * argument >>> i.e. setting an attribute with a single string value, but >>> slapi_get_plugin_default_config() returns multiple values from a >>> single attribute? >>> >>> I'm not sure what the code in usn_start() is doing. Is >>> nsds5ReplicatedAttributeList multi-valued? If so, each char * in >>> char **old_frac_attrs will be a full attribute list description >>> "(objectclass=*) $ EXCLUDE ...". Then I'm not sure what the code >>> that adds the entryusn attribute to the default excluded list is >>> doing - will it add entryusn to only the first value of >>> nsds5ReplicatedAttributeList? And wipe out the other values? I >>> think that's what will happen, since there is a break in the for >>> loop if token == NULL - it will skip old_frac_attrs[1] etc. Also >>> the call to charray_add - the token argument is not a malloced >>> string, so that will cause problems when slapi_ch_array_free() is >>> called. >>> >> I cleaned up the code. It just adds the attribute value as follows. >> /* add nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE >> entryusn >> * to cn=plugin default config,cn=config */ >> rc = slapi_set_plugin_default_config("nsds5ReplicatedAttributeList", >> "(objectclass=*) $ EXCLUDE >> entryusn"); >> >> Sorry about the previous code I wiped out. I wanted to do this... >> Let's assume we found exisiting nsds5ReplicatedAttributeList lines: >> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 >> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type1 type 2 >> I wanted to convert them in to one line: >> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 type1 >> type 2 entryusn >> >> Instead, I changed to just add nsds5ReplicatedAttributeList: >> (objectclass=*) $ EXCLUDE entryusn to the entry. So, it'll end up >> like this: >> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 >> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type1 type 2 >> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn > Ok - will the replication code be able to handle multiple values of > nsds5ReplicatedAttributeList? Yes, it's already in the proposal... (and is tested :) ) --noriko >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Aug 28 15:25:45 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 28 Aug 2009 09:25:45 -0600 Subject: [389-devel] Please review (revised): Plugin Default Config Entry In-Reply-To: <4A97F529.2050004@redhat.com> References: <4A946691.9030905@redhat.com> <4A955F19.8080708@redhat.com> <4A95CA3F.3080404@redhat.com> <4A97E8C9.4020302@redhat.com> <4A97F529.2050004@redhat.com> Message-ID: <4A97F6F9.2020407@redhat.com> Noriko Hosoi wrote: > On 08/28/2009 07:25 AM, Rich Megginson wrote: >> Noriko Hosoi wrote: >>> Thanks a lot, Rich! I revised my proposal based upon your >>> suggestions. Some comments are in-line... >>> --noriko >>> >>> On 08/26/2009 09:13 AM, Rich Megginson wrote: >>> [...] >>>> About this code: >>>> if (new_attrs) >>>> { >>>> - *attrs = new_attrs; >>>> + charray_merge_nodup(attrs, new_attrs, 0); >>>> + slapi_ch_free((void **)&new_attrs); >>>> } >>>> >>>> the 0 flag to charray_merge_nodup() means "do not copy" - so the >>>> strings in new_attrs will be moved to attrs, if they are not >>>> duplicates. If they are duplicates, they will not be moved - how >>>> will they be freed? There's no way for the caller of >>>> charray_merge_nodup to know which strings were moved and which were >>>> not (except by comparing pointers in attrs with new_attrs). >>> I wanted to avoid malloc/free as much as possible, but it looks I >>> cannot... :( Changing it as follows: >>> if (new_attrs) >>> { >>> charray_merge_nodup(attrs, new_attrs, 1); >>> slapi_ch_array_free(new_attrs); >>> } >>> >>>> >>>> + int i; >>>> + const char *val = slapi_value_get_string(sval); >>>> + for (i = slapi_attr_first_value(attr, &sval); >>>> >>>> I don't think you should be calling slapi_value_get_string() here >>>> since sval is not initialized yet. >>> Thanks for finding it out! My copy & paste error... :( Changing it >>> as follows: >>> int i; >>> const char *val = NULL; >>> for (i = slapi_attr_first_value(attr, &sval); >>>> >>>> I think slapi_set_plugin_default_config() should always to a >>>> modify/add, and just ignore "type or value exists" errors. Or >>>> support single valued attributes only. Or allow the user to >>>> specify to add or replace in the case of a multi-valued attribute. >>> I was thinking the value is preferably single, but I wanted to >>> support multiple values if set (e.g., by manually adding dse.ldif as >>> you mentioned). That made the code uglier. I changed >>> slapi_set_plugin_default_config simply adds the given "attr: value" >>> pair to the plugin default config entry instead of replacing the >>> existing pair(s) with it. >>>> What if the user modifies the list directly over LDAP or by editing >>>> dse.ldif? An internal call to set the value will wipe out their >>>> settings. >>> >>>> Also, there is a reference to frational attr in the >>>> slapi_set_plugin_default_config() code. >>> Thanks! I removed it... :p >>>> >>>> I think slapi_set_plugin_default_config() will leak the pblock used >>>> for the initial search if rc != LDAP_SUCCESS or entries is NULL or >>>> empty. >>> I think it's taken care here.... Valgrind shows no leak in >>> slapi_set_plugin_default_config in both cases entries exist or don't >>> exist. >>> 2911 } else { /* cn=plugin default config does not exist. Let's >>> add it. */ >>> 2912 LDAPMod *mods[3]; >>> 2913 LDAPMod mod[2]; >>> 2914 const char *objectclass[3]; >>> 2915 char *attrlist[2]; >>> 2916 *2917 slapi_free_search_results_internal(&pb); >>> 2918 pblock_done(&pb);* >>> >>>> >>>> slapi_get_plugin_default_config() - since you are assuming that the >>>> values of the requested attribute are all null terminated strings >>>> (since you are using slapi_value_get_string()), you could just use >>>> slapi_entry_attr_get_charray() to get all of the values as a char **. >>> Thanks! This is what I needed... >>>> >>>> Why does slapi_set_plugin_default_config() take a char * argument >>>> i.e. setting an attribute with a single string value, but >>>> slapi_get_plugin_default_config() returns multiple values from a >>>> single attribute? >>>> >>>> I'm not sure what the code in usn_start() is doing. Is >>>> nsds5ReplicatedAttributeList multi-valued? If so, each char * in >>>> char **old_frac_attrs will be a full attribute list description >>>> "(objectclass=*) $ EXCLUDE ...". Then I'm not sure what the code >>>> that adds the entryusn attribute to the default excluded list is >>>> doing - will it add entryusn to only the first value of >>>> nsds5ReplicatedAttributeList? And wipe out the other values? I >>>> think that's what will happen, since there is a break in the for >>>> loop if token == NULL - it will skip old_frac_attrs[1] etc. Also >>>> the call to charray_add - the token argument is not a malloced >>>> string, so that will cause problems when slapi_ch_array_free() is >>>> called. >>>> >>> I cleaned up the code. It just adds the attribute value as follows. >>> /* add nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE >>> entryusn >>> * to cn=plugin default config,cn=config */ >>> rc = >>> slapi_set_plugin_default_config("nsds5ReplicatedAttributeList", >>> "(objectclass=*) $ EXCLUDE >>> entryusn"); >>> >>> Sorry about the previous code I wiped out. I wanted to do this... >>> Let's assume we found exisiting nsds5ReplicatedAttributeList lines: >>> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 >>> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type1 type 2 >>> I wanted to convert them in to one line: >>> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 >>> type1 type 2 entryusn >>> >>> Instead, I changed to just add nsds5ReplicatedAttributeList: >>> (objectclass=*) $ EXCLUDE entryusn to the entry. So, it'll end up >>> like this: >>> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type0 >>> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE type1 type 2 >>> nsds5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE entryusn >> Ok - will the replication code be able to handle multiple values of >> nsds5ReplicatedAttributeList? > Yes, it's already in the proposal... (and is tested :) ) > --noriko Ok. Looks good. >>> >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> 389-devel mailing list >>> 389-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Sat Aug 29 02:08:33 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 28 Aug 2009 19:08:33 -0700 Subject: [389-devel] Please review (3rd try): Plugin Default Config Entry In-Reply-To: <4A95CA3F.3080404@redhat.com> References: <4A946691.9030905@redhat.com> <4A955F19.8080708@redhat.com> <4A95CA3F.3080404@redhat.com> Message-ID: <4A988DA1.8000409@redhat.com> Thanks to Endi and Rich for their comments to improve the functionality. I changed the slapi APIs to take and return the Slapi_Value(Set) to support any data type other than string. New slapi APIs in libslapd: int slapi_set_plugin_default_config(const char *type, Slapi_Value *value); Description: Add given "type: value" to the plugin default config entry (cn=plugin default config,cn=config) unless the same "type: value" pair already exists in the entry. Parameters: type - Attribute type to add to the default config entry value - Attribute value to add to the default config entry Return Value: 0 if the operation was successful non-0 if the operation was not successful int slapi_get_plugin_default_config(char *type, Slapi_ValueSet **valueset); Description: Get attribute values of given type from the plugin default config entry (cn=plugin default config,cn=config). Parameters: type - Attribute type to get from the default config entry valueset Valueset holding the attribute values Return Value: 0 if the operation was successful non-0 if the operation was not successful warning: Caller is responsible to free attrs by slapi_ch_array_free Thanks, --noriko -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Plugin-Default-Config-Entry.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Aug 31 14:22:00 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 31 Aug 2009 08:22:00 -0600 Subject: [389-devel] Please review (3rd try): Plugin Default Config Entry In-Reply-To: <4A988DA1.8000409@redhat.com> References: <4A946691.9030905@redhat.com> <4A955F19.8080708@redhat.com> <4A95CA3F.3080404@redhat.com> <4A988DA1.8000409@redhat.com> Message-ID: <4A9BDC88.9030903@redhat.com> Noriko Hosoi wrote: > Thanks to Endi and Rich for their comments to improve the > functionality. I changed the slapi APIs to take and return the > Slapi_Value(Set) to support any data type other than string. > > New slapi APIs in libslapd: > int slapi_set_plugin_default_config(const char *type, Slapi_Value > *value); > Description: Add given "type: value" to the plugin default config entry > (cn=plugin default config,cn=config) unless the same "type: > value" pair already exists in the entry. > Parameters: type - Attribute type to add to the default config entry > value - Attribute value to add to the default config entry > Return Value: 0 if the operation was successful > non-0 if the operation was not successful > > int slapi_get_plugin_default_config(char *type, Slapi_ValueSet > **valueset); > Description: Get attribute values of given type from the plugin default > config entry (cn=plugin default config,cn=config). > Parameters: type - Attribute type to get from the default config entry > valueset Valueset holding the attribute values > Return Value: 0 if the operation was successful > non-0 if the operation was not successful > warning: Caller is responsible to free attrs by slapi_ch_array_free > > Thanks, > --noriko Looks good. ack > > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Mon Aug 31 15:54:19 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 31 Aug 2009 08:54:19 -0700 Subject: [389-devel] Commit (3rd try): Plugin Default Config Entry In-Reply-To: <4A9BDC88.9030903@redhat.com> References: <4A946691.9030905@redhat.com> <4A955F19.8080708@redhat.com> <4A95CA3F.3080404@redhat.com> <4A988DA1.8000409@redhat.com> <4A9BDC88.9030903@redhat.com> Message-ID: <4A9BF22B.3040505@redhat.com> Thanks for the review, Rich! Pushed to master. $ git merge usn Updating 177f772..6b08e5b Fast forward ldap/servers/plugins/replication/repl5_agmt.c | 136 +++++++++++++++++---- ldap/servers/plugins/usn/usn.c | 40 +++++- ldap/servers/plugins/usn/usn.h | 2 +- ldap/servers/slapd/dse.c | 7 +- ldap/servers/slapd/plugin.c | 156 +++++++++++++++++++++++++ ldap/servers/slapd/proto-slap.h | 2 +- ldap/servers/slapd/slapi-plugin.h | 23 ++++ ldap/servers/slapd/slapi-private.h | 2 + 8 files changed, 329 insertions(+), 39 deletions(-) $ git push Counting objects: 31, done. Delta compression using 4 threads. Compressing objects: 100% (16/16), done. Writing objects: 100% (16/16), 5.66 KiB, done. Total 16 (delta 13), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 177f772..6b08e5b master -> master On 08/31/2009 07:22 AM, Rich Megginson wrote: > Noriko Hosoi wrote: >> Thanks to Endi and Rich for their comments to improve the >> functionality. I changed the slapi APIs to take and return the >> Slapi_Value(Set) to support any data type other than string. >> >> New slapi APIs in libslapd: >> int slapi_set_plugin_default_config(const char *type, Slapi_Value >> *value); >> Description: Add given "type: value" to the plugin default config entry >> (cn=plugin default config,cn=config) unless the same >> "type: >> value" pair already exists in the entry. >> Parameters: type - Attribute type to add to the default config entry >> value - Attribute value to add to the default config entry >> Return Value: 0 if the operation was successful >> non-0 if the operation was not successful >> >> int slapi_get_plugin_default_config(char *type, Slapi_ValueSet >> **valueset); >> Description: Get attribute values of given type from the plugin default >> config entry (cn=plugin default config,cn=config). >> Parameters: type - Attribute type to get from the default config entry >> valueset Valueset holding the attribute values >> Return Value: 0 if the operation was successful >> non-0 if the operation was not successful >> warning: Caller is responsible to free attrs by slapi_ch_array_free >> >> Thanks, >> --noriko > Looks good. ack >> >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Aug 31 18:25:33 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 31 Aug 2009 12:25:33 -0600 Subject: [389-devel] Please review: clean up compiler warnings Message-ID: <4A9C159D.90407@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Clean-up-build-warnings.patch Type: text/x-patch Size: 5203 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Mon Aug 31 21:00:10 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 31 Aug 2009 14:00:10 -0700 Subject: [389-devel] Please review: clean up compiler warnings In-Reply-To: <4A9C159D.90407@redhat.com> References: <4A9C159D.90407@redhat.com> Message-ID: <4A9C39DA.1040405@redhat.com> On 08/31/2009 11:25 AM, Rich Megginson wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > Looks good. Thanks, Rich... --noriko -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Aug 31 21:19:26 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 31 Aug 2009 15:19:26 -0600 Subject: [389-devel] Please review: clean up compiler warnings In-Reply-To: <4A9C39DA.1040405@redhat.com> References: <4A9C159D.90407@redhat.com> <4A9C39DA.1040405@redhat.com> Message-ID: <4A9C3E5E.3000606@redhat.com> Noriko Hosoi wrote: > On 08/31/2009 11:25 AM, Rich Megginson wrote: >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > Looks good. > Thanks, Rich... Thanks - pushed to master > --noriko > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: