From nkinder at redhat.com Thu Jul 2 15:53:55 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 02 Jul 2009 08:53:55 -0700 Subject: [389-devel] [PATCH] Bug: 509401 - dnaNextValue not updated when dnaMaxValue set to -1 Message-ID: <4A4CD813.1080809@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Bug-509401-dnaNextValue-not-updated-when-dnaMaxVa.patch URL: From rmeggins at redhat.com Thu Jul 2 16:32:33 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 02 Jul 2009 10:32:33 -0600 Subject: [389-devel] [PATCH] Bug: 509401 - dnaNextValue not updated when dnaMaxValue set to -1 In-Reply-To: <4A4CD813.1080809@redhat.com> References: <4A4CD813.1080809@redhat.com> Message-ID: <4A4CE121.10204@redhat.com> Nathan Kinder wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel ok -------------- 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 Thu Jul 2 16:55:56 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 02 Jul 2009 09:55:56 -0700 Subject: [389-devel] [PATCH] Bug: 509401 - dnaNextValue not updated when dnaMaxValue set to -1 In-Reply-To: <4A4CE121.10204@redhat.com> References: <4A4CD813.1080809@redhat.com> <4A4CE121.10204@redhat.com> Message-ID: <4A4CE69C.1000500@redhat.com> Rich Megginson wrote: > Nathan Kinder wrote: >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > ok Pushed to master. > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > From rmeggins at redhat.com Mon Jul 6 19:20:22 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 06 Jul 2009 13:20:22 -0600 Subject: [389-devel] Please review: OpenLDAP support Message-ID: <4A524E76.7020206@redhat.com> Note - the patch does not contain the diffs for configure nor Makefile.in http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch -------------- 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 Mon Jul 6 22:53:25 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 06 Jul 2009 15:53:25 -0700 Subject: [389-devel] Please review: OpenLDAP support In-Reply-To: <4A524E76.7020206@redhat.com> References: <4A524E76.7020206@redhat.com> Message-ID: <4A528065.6090909@redhat.com> On 07/06/2009 12:20 PM, Rich Megginson wrote: > Note - the patch does not contain the diffs for configure nor Makefile.in > http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch There are a few minor log message formatting issues that I noticed: - Do a grep for "insee_if_write_available" for the first one. A space just needs to be added between "in" and "see_if_write_available". - The '\' was left off of a '\n' in the following call to slapi_log_error in slapi_ldap_init_ext(): slapi_log_error(SLAPI_LOG_FATAL, "slapi_ldap_init_ext", "failed: unable to set minimum TLS protocol level to SSL3n"); - The next call to slapi_log_error is also missing the '\n' in slapi_ldap_init_ext(). The patch looks good aside from the above nit-picks (though it's a large patch, so I could have missed something). -NGK > ------------------------------------------------------------------------ > > -- > 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 Jul 7 14:34:31 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 07 Jul 2009 08:34:31 -0600 Subject: [389-devel] Please review: OpenLDAP support In-Reply-To: <4A528065.6090909@redhat.com> References: <4A524E76.7020206@redhat.com> <4A528065.6090909@redhat.com> Message-ID: <4A535CF7.6040104@redhat.com> Nathan Kinder wrote: > On 07/06/2009 12:20 PM, Rich Megginson wrote: >> Note - the patch does not contain the diffs for configure nor >> Makefile.in >> http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch > There are a few minor log message formatting issues that I noticed: > > - Do a grep for "insee_if_write_available" for the first one. A space > just needs to be added between "in" and "see_if_write_available". > > - The '\' was left off of a '\n' in the following call to > slapi_log_error in slapi_ldap_init_ext(): > > slapi_log_error(SLAPI_LOG_FATAL, "slapi_ldap_init_ext", > "failed: unable to set minimum TLS > protocol level to SSL3n"); > > - The next call to slapi_log_error is also missing the '\n' in > slapi_ldap_init_ext(). > > The patch looks good aside from the above nit-picks (though it's a > large patch, so I could have missed something). Thanks. I fixed these, and pushed to master. > > -NGK >> ------------------------------------------------------------------------ >> >> -- >> 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 hyc at symas.com Tue Jul 7 17:37:07 2009 From: hyc at symas.com (Howard Chu) Date: Tue, 07 Jul 2009 10:37:07 -0700 Subject: [389-devel] Re: Please review: OpenLDAP support In-Reply-To: <20090707160043.99BAD8E01D6@hormel.redhat.com> References: <20090707160043.99BAD8E01D6@hormel.redhat.com> Message-ID: <4A5387C3.8090505@symas.com> > Message: 1 > Date: Mon, 06 Jul 2009 13:20:22 -0600 > From: Rich Megginson > Note - the patch does not contain the diffs for configure nor Makefile.in > http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch We probably should talk about exposing the UTF8 APIs. The only reason they were kept private is because they weren't part of the RFC1823 or the expired C API draft, but they've been present for at least the past 9 years. re: ldif_read_record() and the public LDIF API, note our ITS#5892; some of the function signatures here will change soon so that error can be distinguished from EOF. (But since 2.4's APIs are supposed to be frozen it may wait until 2.5.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From rmeggins at redhat.com Tue Jul 7 18:38:24 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 07 Jul 2009 12:38:24 -0600 Subject: [389-devel] Re: Please review: OpenLDAP support In-Reply-To: <4A5387C3.8090505@symas.com> References: <20090707160043.99BAD8E01D6@hormel.redhat.com> <4A5387C3.8090505@symas.com> Message-ID: <4A539620.7050107@redhat.com> Howard Chu wrote: > >> Message: 1 >> Date: Mon, 06 Jul 2009 13:20:22 -0600 >> From: Rich Megginson > >> Note - the patch does not contain the diffs for configure nor >> Makefile.in >> http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch > > We probably should talk about exposing the UTF8 APIs. The only reason > they were kept private is because they weren't part of the RFC1823 or > the expired C API draft, but they've been present for at least the > past 9 years. Yeah, the utf8 API is in kind of a weird place. Some stuff is provided by the OS, like utf8 <-> charset conversion (iconv), some stuff is provided by third party libraries we already use (ICU). It's really odd that an LDAP library should provide a utf8 API - it just seems as though there should be a more widespread utf8 API library (ICU is very heavyweight if that's all you're going to use it for - a sledgehammer for a thumbtack). However, since utf8 is so integral to LDAP, having LDAP expose a useful API would be a good thing. > > re: ldif_read_record() and the public LDIF API, note our ITS#5892; > some of the function signatures here will change soon so that error > can be distinguished from EOF. (But since 2.4's APIs are supposed to > be frozen it may wait until 2.5.) Ok. We will have to track that and be prepared when the change occurs. Thanks for the heads-up. -------------- 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 Jul 7 19:25:57 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 07 Jul 2009 13:25:57 -0600 Subject: [389-devel] Please review: clean up compiler warnings Message-ID: <4A53A145.5050603@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Clean-up-compiler-warnings.patch Type: text/x-patch Size: 9105 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 Jul 7 19:38:56 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 07 Jul 2009 12:38:56 -0700 Subject: [389-devel] Please review: clean up compiler warnings In-Reply-To: <4A53A145.5050603@redhat.com> References: <4A53A145.5050603@redhat.com> Message-ID: <4A53A450.6090908@redhat.com> ack. On 07/07/2009 12:25 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 Jul 7 19:46:45 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 07 Jul 2009 13:46:45 -0600 Subject: [389-devel] Please review: clean up compiler warnings In-Reply-To: <4A53A450.6090908@redhat.com> References: <4A53A145.5050603@redhat.com> <4A53A450.6090908@redhat.com> Message-ID: <4A53A625.8050608@redhat.com> Nathan Kinder wrote: > ack. Thanks pushed > > On 07/07/2009 12:25 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 hyc at symas.com Wed Jul 8 00:44:49 2009 From: hyc at symas.com (Howard Chu) Date: Tue, 07 Jul 2009 17:44:49 -0700 Subject: [389-devel] Re: Please review: OpenLDAP support In-Reply-To: <4A5387C3.8090505@symas.com> References: <20090707160043.99BAD8E01D6@hormel.redhat.com> <4A5387C3.8090505@symas.com> Message-ID: <4A53EC01.5060607@symas.com> Howard Chu wrote: > >> Message: 1 >> Date: Mon, 06 Jul 2009 13:20:22 -0600 >> From: Rich Megginson > >> Note - the patch does not contain the diffs for configure nor Makefile.in >> http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch As noted in your patch, the OpenLDAP API doesn't provide any options to control SSL session caching. In the past I hacked that into my clients by retrieving the OpenSSL context handles and using the OpenSSL API directly. Obviously that's not a viable way forward since we now have 3 different TLS libraries to deal with. So, we will probably be adding a couple set_option() flags for this purpose Real Soon Now. If there's anything good or bad about the way MozLDAP handles this, let me know what you think... We'll also be providing a callback for obtaining the password for the private key... Again that's something we've ignored because OpenSSL has provided its own for so long. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From rmeggins at redhat.com Wed Jul 8 03:02:47 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 07 Jul 2009 21:02:47 -0600 Subject: [389-devel] Re: Please review: OpenLDAP support In-Reply-To: <4A53EC01.5060607@symas.com> References: <20090707160043.99BAD8E01D6@hormel.redhat.com> <4A5387C3.8090505@symas.com> <4A53EC01.5060607@symas.com> Message-ID: <4A540C57.2040102@redhat.com> Howard Chu wrote: > Howard Chu wrote: >> >>> Message: 1 >>> Date: Mon, 06 Jul 2009 13:20:22 -0600 >>> From: Rich Megginson >> >>> Note - the patch does not contain the diffs for configure nor >>> Makefile.in >>> http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch > > As noted in your patch, the OpenLDAP API doesn't provide any options > to control SSL session caching. In the past I hacked that into my > clients by retrieving the OpenSSL context handles and using the > OpenSSL API directly. Obviously that's not a viable way forward since > we now have 3 different TLS libraries to deal with. So, we will > probably be adding a couple set_option() flags for this purpose Real > Soon Now. If there's anything good or bad about the way MozLDAP > handles this, let me know what you think... Actually, the way we do it is bad, which is to disable caching on outgoing SSL connections. Nelson commented on this in a thread on mozilla.dev.tech.crypto. I think you use SSL_SetSockPeerID() but I'd have to look up that thread to be sure. > > We'll also be providing a callback for obtaining the password for the > private key... Again that's something we've ignored because OpenSSL > has provided its own for so long. This is tricky - with MozNSS you have to do this before you detach from the terminal, but after you fork(). -------------- 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 rcritten at redhat.com Wed Jul 8 12:53:58 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 08 Jul 2009 08:53:58 -0400 Subject: [389-devel] Re: Please review: OpenLDAP support In-Reply-To: <4A53EC01.5060607@symas.com> References: <20090707160043.99BAD8E01D6@hormel.redhat.com> <4A5387C3.8090505@symas.com> <4A53EC01.5060607@symas.com> Message-ID: <4A5496E6.50402@redhat.com> Howard Chu wrote: > Howard Chu wrote: >> >>> Message: 1 >>> Date: Mon, 06 Jul 2009 13:20:22 -0600 >>> From: Rich Megginson >> >>> Note - the patch does not contain the diffs for configure nor >>> Makefile.in >>> http://rmeggins.fedorapeople.org/0001-OpenLDAP-support.patch > > As noted in your patch, the OpenLDAP API doesn't provide any options to > control SSL session caching. In the past I hacked that into my clients > by retrieving the OpenSSL context handles and using the OpenSSL API > directly. Obviously that's not a viable way forward since we now have 3 > different TLS libraries to deal with. So, we will probably be adding a > couple set_option() flags for this purpose Real Soon Now. If there's > anything good or bad about the way MozLDAP handles this, let me know > what you think... > > We'll also be providing a callback for obtaining the password for the > private key... Again that's something we've ignored because OpenSSL has > provided its own for so long. > libcurl has a similar SSL abstraction layer that works with OpenSSL, GnuTLS and NSS. You might find some inspiration there. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Jul 8 15:53:14 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 08 Jul 2009 09:53:14 -0600 Subject: [389-devel] more git lore Message-ID: <4A54C0EA.3040608@redhat.com> I've updated this page with some more git stuff that I find useful. Please update with stuff that you find useful too. http://directory.fedoraproject.org/wiki/GIT_Rules -------------- 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 Jul 14 15:11:54 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 14 Jul 2009 09:11:54 -0600 Subject: [389-devel] Please review: Reduce noise reported by valgrind Message-ID: <4A5CA03A.1060500@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Reduce-noise-reported-by-valgrind.patch Type: text/x-patch Size: 47090 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 Tue Jul 14 16:58:29 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 14 Jul 2009 09:58:29 -0700 Subject: [389-devel] Please review: Reduce noise reported by valgrind In-Reply-To: <4A5CA03A.1060500@redhat.com> References: <4A5CA03A.1060500@redhat.com> Message-ID: <4A5CB935.9020504@redhat.com> Rich Megginson wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel Your fixes look good. --noriko -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Tue Jul 14 17:20:47 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 14 Jul 2009 10:20:47 -0700 Subject: [389-devel] Please review: Reduce noise reported by valgrind In-Reply-To: <4A5CA03A.1060500@redhat.com> References: <4A5CA03A.1060500@redhat.com> Message-ID: <4A5CBE6F.4060305@redhat.com> Looks good. I'll be happy to see those NSS_Initialize leak reports go away. On 07/14/2009 08:11 AM, 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 Jul 14 18:37:01 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 14 Jul 2009 12:37:01 -0600 Subject: [389-devel] Please review: Reduce noise reported by valgrind In-Reply-To: <4A5CBE6F.4060305@redhat.com> References: <4A5CA03A.1060500@redhat.com> <4A5CBE6F.4060305@redhat.com> Message-ID: <4A5CD04D.9060107@redhat.com> Nathan Kinder wrote: > Looks good. I'll be happy to see those NSS_Initialize leak reports go > away. Thanks to you and Noriko. Pushed > > On 07/14/2009 08:11 AM, 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 Tue Jul 14 18:54:27 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 14 Jul 2009 12:54:27 -0600 Subject: [389-devel] Please review: fix attrcrypt usage of nsSymmetricKey Message-ID: <4A5CD463.5090505@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-attrcrypt-usage-of-nsSymmetricKey.patch Type: text/x-patch Size: 7210 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 Jul 14 19:48:11 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 14 Jul 2009 12:48:11 -0700 Subject: [389-devel] Please review: fix attrcrypt usage of nsSymmetricKey In-Reply-To: <4A5CD463.5090505@redhat.com> References: <4A5CD463.5090505@redhat.com> Message-ID: <4A5CE0FB.9080602@redhat.com> On 07/14/2009 11:54 AM, Rich Megginson wrote: > ation because the binary values in the key do not conform to > DirectoryString. The code was poorly designed to handle and report errors of > this nature. The real fix is to add nsSymmetricKey as a BINARY syntax > attribute. I also cleaned up the error detection ack. From rmeggins at redhat.com Tue Jul 14 20:42:20 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 14 Jul 2009 14:42:20 -0600 Subject: [389-devel] Please review: fix attrcrypt usage of nsSymmetricKey In-Reply-To: <4A5CE0FB.9080602@redhat.com> References: <4A5CD463.5090505@redhat.com> <4A5CE0FB.9080602@redhat.com> Message-ID: <4A5CEDAC.6050005@redhat.com> Nathan Kinder wrote: > On 07/14/2009 11:54 AM, Rich Megginson wrote: >> ation because the binary values in the key do not conform to >> DirectoryString. The code was poorly designed to handle and report >> errors of >> this nature. The real fix is to add nsSymmetricKey as a BINARY syntax >> attribute. I also cleaned up the error detection > ack. pushed > > -- > 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 nkinder at redhat.com Tue Jul 14 21:52:32 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 14 Jul 2009 14:52:32 -0700 Subject: [389-devel] Please Review: Add additional standard syntaxes Message-ID: <4A5CFE20.6030108@redhat.com> This adds support for the following standard syntaxes, complete with validation functions: Bit String Delivery Method Enhanced Guide Facsimile Telephone Number Fax Guide Name And Optional UID Printable String Teletex Terminal Identifier Telex Number This patch does not change the schema to use any of these syntaxes yet. That will come when we update to the current versions of the standard schema from the LDAP RFCs. I also fixed an error in makefile.am where Setup.pm was listed twice in perl_DATA. I have omitted the generated build files from the diffs. If you want the full patch to apply to a local git tree, I made it available at: http://nkinder.fedorapeople.org/0001-Add-additional-standard-syntaxes.patch -NGK -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: newsyntaxes.diff URL: From nhosoi at redhat.com Tue Jul 14 23:06:17 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 14 Jul 2009 16:06:17 -0700 Subject: [389-devel] Please Review: Add additional standard syntaxes In-Reply-To: <4A5CFE20.6030108@redhat.com> References: <4A5CFE20.6030108@redhat.com> Message-ID: <4A5D0F69.40409@redhat.com> Looks good! --noriko Nathan Kinder wrote: > This adds support for the following standard syntaxes, complete > with validation functions: > > Bit String > Delivery Method > Enhanced Guide > Facsimile Telephone Number > Fax > Guide > Name And Optional UID > Printable String > Teletex Terminal Identifier > Telex Number > > This patch does not change the schema to use any of these syntaxes > yet. That will come when we update to the current versions of the > standard schema from the LDAP RFCs. > > I also fixed an error in makefile.am where Setup.pm was listed > twice in perl_DATA. > > I have omitted the generated build files from the diffs. If you want > the full patch to apply to a local git tree, I made it available at: > > > http://nkinder.fedorapeople.org/0001-Add-additional-standard-syntaxes.patch > > > -NGK > ------------------------------------------------------------------------ > > -- > 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: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Jul 14 23:10:40 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 14 Jul 2009 17:10:40 -0600 Subject: [389-devel] Please Review: Add additional standard syntaxes In-Reply-To: <4A5CFE20.6030108@redhat.com> References: <4A5CFE20.6030108@redhat.com> Message-ID: <4A5D1070.9040407@redhat.com> Nathan Kinder wrote: > This adds support for the following standard syntaxes, complete > with validation functions: > > Bit String > Delivery Method > Enhanced Guide > Facsimile Telephone Number > Fax > Guide > Name And Optional UID > Printable String > Teletex Terminal Identifier > Telex Number > > This patch does not change the schema to use any of these syntaxes > yet. That will come when we update to the current versions of the > standard schema from the LDAP RFCs. > > I also fixed an error in makefile.am where Setup.pm was listed > twice in perl_DATA. > > I have omitted the generated build files from the diffs. If you want > the full patch to apply to a local git tree, I made it available at: > > > http://nkinder.fedorapeople.org/0001-Add-additional-standard-syntaxes.patch > Looks good. > > -NGK > ------------------------------------------------------------------------ > > -- > 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 nkinder at redhat.com Tue Jul 14 23:21:43 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 14 Jul 2009 16:21:43 -0700 Subject: [389-devel] Please Review: Add additional standard syntaxes In-Reply-To: <4A5D0F69.40409@redhat.com> References: <4A5CFE20.6030108@redhat.com> <4A5D0F69.40409@redhat.com> Message-ID: <4A5D1307.6070606@redhat.com> On 07/14/2009 04:06 PM, Noriko Hosoi wrote: > Looks good! Pushed to master. Thanks to Rich and Noriko for their reviews! > --noriko > > Nathan Kinder wrote: >> This adds support for the following standard syntaxes, complete >> with validation functions: >> >> Bit String >> Delivery Method >> Enhanced Guide >> Facsimile Telephone Number >> Fax >> Guide >> Name And Optional UID >> Printable String >> Teletex Terminal Identifier >> Telex Number >> >> This patch does not change the schema to use any of these syntaxes >> yet. That will come when we update to the current versions of the >> standard schema from the LDAP RFCs. >> >> I also fixed an error in makefile.am where Setup.pm was listed >> twice in perl_DATA. >> >> I have omitted the generated build files from the diffs. If you want >> the full patch to apply to a local git tree, I made it available at: >> >> >> http://nkinder.fedorapeople.org/0001-Add-additional-standard-syntaxes.patch >> >> >> -NGK >> ------------------------------------------------------------------------ >> >> -- >> 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 Wed Jul 15 16:31:37 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 15 Jul 2009 10:31:37 -0600 Subject: [389-devel] Please review: Fix unsalted password comparisons Message-ID: <4A5E0469.4000204@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-unsalted-password-comparisons.patch Type: text/x-patch Size: 2077 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 Wed Jul 15 21:07:08 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 15 Jul 2009 14:07:08 -0700 Subject: [389-devel] Please review: Fix unsalted password comparisons In-Reply-To: <4A5E0469.4000204@redhat.com> References: <4A5E0469.4000204@redhat.com> Message-ID: <4A5E44FC.1000201@redhat.com> Rich Megginson wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel Looks good. --noriko -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Jul 15 21:24:39 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 15 Jul 2009 15:24:39 -0600 Subject: [389-devel] Please review: Fix unsalted password comparisons In-Reply-To: <4A5E44FC.1000201@redhat.com> References: <4A5E0469.4000204@redhat.com> <4A5E44FC.1000201@redhat.com> Message-ID: <4A5E4917.7080601@redhat.com> Noriko Hosoi wrote: > Rich Megginson wrote: >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > Looks good. Thanks. Pushed. > --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: From nkinder at redhat.com Wed Jul 15 21:24:13 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 15 Jul 2009 14:24:13 -0700 Subject: [389-devel] Please Review: (479753) Update core schema to latest defined in LDAP RFCs Message-ID: <4A5E48FD.4090905@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=479753 Resolves: Bug 479753 Description: Update core schema to latest defined in LDAP RFCs Fix Description: This patch updates and reorganizes our core schema to follow the most recently defined standards. The layout of the core schema files is as follows: 00core.ldif - RFC 4512, RFC 4519, LDAP Subentry Internet Draft 01core389.ldif - 389 specific schema (required to start server) 02common.ldif - 389 specific schema (highly recommended, Changelog Internet Draft, plug-in schema) 05rfc2927.ldif - MIME Directory Profile for LDAP Schema 05rfc4523.ldif - Schema Definitions for X.509 Certificates 05rfc4524.ldif - Cosine LDAP/X.500 Schema 06inetorgperson.ldif - RFC 2798 (pulls in RFC 2079 and part of the obsolete RFC 1274 due to required attributes) There are still a handful of syntaxes that we don't support, so I've substituted syntaxes for about 15 attributes. The schema and DIT related description syntaxes are not supported, so I've used the "Directory String" syntax instead in 00core.ldif. The certificate syntaxes defined in 4523 are not supported, so I've used the "Octet String" syntax instead. All of these deviations are commented with a "TODO" listing the syntax that we need to implement. I have also updated the Mozilla address book schema to the latest from upstream for a minor bug fix. I changed the nsSymmetricKey attribute to use the "Octet String" syntax since the "Binary" syntax is deprecated. Platforms tested: F9 x86_64, F11 x86_64 https://bugzilla.redhat.com/attachment.cgi?id=353910&action=diff From nkinder at redhat.com Thu Jul 16 15:02:04 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 16 Jul 2009 08:02:04 -0700 Subject: [389-devel] Please Review: (479753) Update core schema to latest defined in LDAP RFCs In-Reply-To: <4A5E48FD.4090905@redhat.com> References: <4A5E48FD.4090905@redhat.com> Message-ID: <4A5F40EC.7060409@redhat.com> On 07/15/2009 02:24 PM, Nathan Kinder wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=479753 > Resolves: Bug 479753 > Description: Update core schema to latest defined in LDAP RFCs > Fix Description: This patch updates and reorganizes our core schema to > follow the most recently defined standards. The layout of the core > schema files is as follows: > > 00core.ldif - RFC 4512, RFC 4519, LDAP Subentry Internet Draft > 01core389.ldif - 389 specific schema (required to start server) > 02common.ldif - 389 specific schema (highly recommended, > Changelog Internet Draft, plug-in schema) > 05rfc2927.ldif - MIME Directory Profile for LDAP Schema > 05rfc4523.ldif - Schema Definitions for X.509 Certificates > 05rfc4524.ldif - Cosine LDAP/X.500 Schema > 06inetorgperson.ldif - RFC 2798 (pulls in RFC 2079 and part of > the obsolete RFC 1274 due to required attributes) > > There are still a handful of syntaxes that we don't support, so > I've substituted syntaxes for about 15 attributes. The schema and > DIT related description syntaxes are not supported, so I've used > the "Directory String" syntax instead in 00core.ldif. The > certificate syntaxes defined in 4523 are not supported, so I've > used the "Octet String" syntax instead. All of these deviations > are commented with a "TODO" listing the syntax that we need to > implement. > > I have also updated the Mozilla address book schema to the latest > from upstream for a minor bug fix. I changed the nsSymmetricKey > attribute to use the "Octet String" syntax since the "Binary" > syntax is deprecated. > > Platforms tested: F9 x86_64, F11 x86_64 > https://bugzilla.redhat.com/attachment.cgi?id=353910&action=diff Pushed to master. Thanks to Rich for his review! > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel From andrey.ivanov at polytechnique.fr Sat Jul 18 14:44:42 2009 From: andrey.ivanov at polytechnique.fr (Andrey Ivanov) Date: Sat, 18 Jul 2009 16:44:42 +0200 Subject: [389-devel] USN Design Document Message-ID: <1601b8650907180744o4ea2e122yc067dcbe6f9f3aa6@mail.gmail.com> I've seen some changes in the USN design document, so i'll add my two cents. Overall it's well written, the architecture seems to be rather robust. There are some scenarious that are interesting for us as for the behaviour of the usn plugin and some questions/reflections : * The USNs seem to be unique within a suffix/backend. Should we enable the uniqueness plug-in for them? If not can we be sure that a manual change of entryUSN will not interfere with the correct functioning of the plug-in? * When the plug-in is activated no entry has entryUSN or maybe some entries do already have it in some desorder. Maybe we should initialise (while plug-in in started for the VERY first time) all the entries without entryUSN with entryUSN=-1 or smth like that? * Maybe it's a good idea to desactivate the replication of entryUSN attribute during the server installation by default? * When we do an export with a utility like db2ldif.pl - should the entryUSN attributes be exported or not? * What happens during the import of a whole ldif subtree by smth like "ldif2db -n userRoot -i /tmp/current_prod_database.ldif" if the entryUSNs are already present in the imported ldif? If they are not present? if they are present only in a part of the entries? * Should usn-tombstone-cleanup be integrated in the server core with the thread purging the tombstones ot not? Should it be configurable bo some attributes like nsds5ReplicaPurgeDelay and nsds5ReplicaTombstonePurgeInterval? And thank you for your work! From nhosoi at redhat.com Sun Jul 19 01:15:32 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Sat, 18 Jul 2009 18:15:32 -0700 Subject: [389-devel] USN Design Document In-Reply-To: <1601b8650907180744o4ea2e122yc067dcbe6f9f3aa6@mail.gmail.com> References: <1601b8650907180744o4ea2e122yc067dcbe6f9f3aa6@mail.gmail.com> Message-ID: <4A6273B4.50102@redhat.com> Thank you so much for your comments and suggestions, Andrey! Some look easy (e.g., the first item -- I'm turning it on and run more tests), and some look more challenging. I'm going to make a ToDo section in the wiki page and add your list to the section. Thanks, again. --noriko Andrey Ivanov wrote: > I've seen some changes in the USN design document, so i'll add my two > cents. Overall it's well written, the architecture seems to be rather > robust. There are some scenarious that are interesting for us as for > the behaviour of the usn plugin and some questions/reflections : > > * The USNs seem to be unique within a suffix/backend. Should we enable > the uniqueness plug-in for them? If not can we be sure that a manual > change of entryUSN will not interfere with the correct functioning of > the plug-in? > * When the plug-in is activated no entry has entryUSN or maybe some > entries do already have it in some desorder. Maybe we should > initialise (while plug-in in started for the VERY first time) all the > entries without entryUSN with entryUSN=-1 or smth like that? > * Maybe it's a good idea to desactivate the replication of entryUSN > attribute during the server installation by default? > * When we do an export with a utility like db2ldif.pl - should the > entryUSN attributes be exported or not? > * What happens during the import of a whole ldif subtree by smth like > "ldif2db -n userRoot -i /tmp/current_prod_database.ldif" if the > entryUSNs are already present in the imported ldif? If they are not > present? if they are present only in a part of the entries? > * Should usn-tombstone-cleanup be integrated in the server core with > the thread purging the tombstones ot not? Should it be configurable bo > some attributes like nsds5ReplicaPurgeDelay and > nsds5ReplicaTombstonePurgeInterval? > > And thank you for your work! > > -- > 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: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Mon Jul 20 16:35:58 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 20 Jul 2009 09:35:58 -0700 Subject: [389-devel] Please Review: Skip syntax check when importing pre-encrypted attributes Message-ID: <4A649CEE.5030305@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Skip-syntax-check-of-encrypted-attributes-during-imp.patch URL: From nhosoi at redhat.com Mon Jul 20 17:34:16 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 20 Jul 2009 10:34:16 -0700 Subject: [389-devel] Please Review: Skip syntax check when importing pre-encrypted attributes In-Reply-To: <4A649CEE.5030305@redhat.com> References: <4A649CEE.5030305@redhat.com> Message-ID: <4A64AA98.6050907@redhat.com> Nathan Kinder wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel Looks good! --noriko -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Mon Jul 20 17:44:08 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 20 Jul 2009 10:44:08 -0700 Subject: [389-devel] Please Review: Skip syntax check when importing pre-encrypted attributes In-Reply-To: <4A64AA98.6050907@redhat.com> References: <4A649CEE.5030305@redhat.com> <4A64AA98.6050907@redhat.com> Message-ID: <4A64ACE8.8040706@redhat.com> On 07/20/2009 10:34 AM, Noriko Hosoi wrote: > Nathan Kinder wrote: >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > Looks good! Pushed to master. Thanks for the review! > --noriko > ------------------------------------------------------------------------ > > -- > 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 Mon Jul 20 20:55:43 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 20 Jul 2009 13:55:43 -0700 Subject: [389-devel] Please review: Entry USN Message-ID: <4A64D9CF.5090204@redhat.com> First cut for implementing Entry USN. See http://directory.fedoraproject.org/wiki/Entry_USN for the design details. This change includes a bug fix for "db2ldif -r"; event queue system was not shutdown before the plugins are closed, which could have crashed the command line utility. Thanks, --noriko -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Entry-USN.patch Type: text/x-patch Size: 106326 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Tue Jul 21 15:07:34 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 21 Jul 2009 08:07:34 -0700 Subject: [389-devel] Please Review: Use LDAPv3 DN values in ns-newpwpolicy script Message-ID: <4A65D9B6.2040908@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Use-LDAPv3-DN-values-in-ns-newpwpolicy-script.patch URL: From nhosoi at redhat.com Tue Jul 21 15:47:56 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 21 Jul 2009 08:47:56 -0700 Subject: [389-devel] Please Review: Use LDAPv3 DN values in ns-newpwpolicy script In-Reply-To: <4A65D9B6.2040908@redhat.com> References: <4A65D9B6.2040908@redhat.com> Message-ID: <4A65E32C.7060509@redhat.com> Nathan Kinder wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel Looks good. --noriko -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Tue Jul 21 16:09:27 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 21 Jul 2009 09:09:27 -0700 Subject: [389-devel] Please Review: Use LDAPv3 DN values in ns-newpwpolicy script In-Reply-To: <4A65E32C.7060509@redhat.com> References: <4A65D9B6.2040908@redhat.com> <4A65E32C.7060509@redhat.com> Message-ID: <4A65E837.6070406@redhat.com> On 07/21/2009 08:47 AM, Noriko Hosoi wrote: > Nathan Kinder wrote: >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > Looks good. Pushed to master. Thanks for the review! -NGK > --noriko > ------------------------------------------------------------------------ > > -- > 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 Jul 21 17:40:48 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 21 Jul 2009 10:40:48 -0700 Subject: [389-devel] Please review: [Bug 513019] nsslapd-lookthroughlimit is not respected when the filter test failed in search In-Reply-To: References: Message-ID: <4A65FDA0.90708@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=513019 Summary: nsslapd-lookthroughlimit is not respected when the filter test failed in search Product: 389 Version: 1.2.0 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: Database - Indexes/Searches AssignedTo: nhosoi at redhat.com ReportedBy: nhosoi at redhat.com QAContact: ckannan at redhat.com CC: sramling at redhat.com Blocks: 434915 Estimated Hours: 0.0 Classification: Other Target Release: --- Description of problem: Bug report by Sankar Ramalingam: Test Setup 1: Simple paged with sorting with all default configuration values except nsslapd-lookthroughlimit is set to 100 Added 400 users to the suffix. Simple paged search request with normal user. perl ./data/ldap_usr_search.pl -x -pg 90 "cn=test*" -S "cn" "dn" Problem sorting, LDAP_ADMIN_LIMIT_EXCEEDED next page size (90): Result; This returns 90 entries and the ADMIN_LIMIT_EXCEEDED error. perl ./data/ldap_usr_search.pl -x -pg 91 "cn=test*" -S "cn" "dn" search failed: LDAP_ADMIN_LIMIT_EXCEEDED Result: Search fails. Though the limit is set to 100, it fails for 91st entry. [Proposed Fix] Created an attachment (id=354532) --> (https://bugzilla.redhat.com/attachment.cgi?id=354532) git patch file for ldbm_search.c File: ldap/servers/slapd/back-ldbm/ldbm_search.c Fix Description: When filter test is necessary against the search results and the test fails, lookthroughcount attached to the search result structure should have been decremented since the entry will not be sent to the client, but it was not. This change fixes it. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From nhosoi at redhat.com Tue Jul 21 20:08:39 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 21 Jul 2009 13:08:39 -0700 Subject: [389-devel] Entry USN (additional changes) In-Reply-To: <4A64D9CF.5090204@redhat.com> References: <4A64D9CF.5090204@redhat.com> Message-ID: <4A662047.6040008@redhat.com> Regarding the first question from Andrey: The USNs seem to be unique within a suffix/backend. Should we enable the uniqueness plug-in for them? If not can we be sure that a manual change of entryUSN will not interfere with the correct functioning of the plug-in? Nathan suggested to set SLAPI_ATTR_FLAG_NOUSERMOD to the attribute entryusn as follows. diff --git a/ldap/servers/slapd/back-ldbm/init.c b/ldap/servers/slapd/back-ldbm/ index a4ff79c..be9c114 100644 --- a/ldap/servers/slapd/back-ldbm/init.c +++ b/ldap/servers/slapd/back-ldbm/init.c @@ -86,7 +86,7 @@ ldbm_back_add_schema( Slapi_PBlock *pb ) rc |= add_ldbm_internal_attr_syntax( "entryusn", LDBM_ENTRYUSN_OID, INTEGER_SYNTAX_OID, INTFIRSTCOMPMATCH - SLAPI_ATTR_FLAG_SINGLE ); + SLAPI_ATTR_FLAG_SINGLE|SLAPI_ATTR_FLAG_NOUSERMOD ); return rc; } The flag nicely prevents the manual update on EntryUSN. ldapmodify -D "cn=Directory Manager" -w /password/ dn: uid=tuserX,dc=example,dc=com changetype: modify replace: entryusn entryusn: 100 modifying entry uid=tuserX,dc=example,dc=com ldap_modify: DSA is unwilling to perform ldap_modify: additional info: no modifiable attributes specified Nathan also pointed out several typos as well as an issue of internal deletion. Currently, if the delete is initiated internally, the entry is not converted to a tombstone unless the backend is replicated. I'm adding this issue to ToDo list for now. Attached patch includes the above diff and typo fixes. Thanks so much to Nathan for his reviews and suggestions. --noriko Noriko Hosoi wrote: > First cut for implementing Entry USN. > See http://directory.fedoraproject.org/wiki/Entry_USN for the design > details. > This change includes a bug fix for "db2ldif -r"; event queue system > was not > shutdown before the plugins are closed, which could have crashed the > command > line utility. > > Thanks, > --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: 0001-Entry-USN.patch Type: text/x-patch Size: 106348 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3250 bytes Desc: S/MIME Cryptographic Signature URL: From andrey.ivanov at polytechnique.fr Tue Jul 21 21:27:21 2009 From: andrey.ivanov at polytechnique.fr (Andrey Ivanov) Date: Tue, 21 Jul 2009 23:27:21 +0200 Subject: [389-devel] Entry USN (additional changes) In-Reply-To: <4A662047.6040008@redhat.com> References: <4A64D9CF.5090204@redhat.com> <4A662047.6040008@redhat.com> Message-ID: <1601b8650907211427u34526b2bu8001ac3c37c66289@mail.gmail.com> Hi, > Nathan also pointed out several typos as well as an issue of internal > deletion. ?Currently, if the delete is initiated internally, the entry is > not converted to a tombstone unless the backend is replicated. ?I'm adding > this issue to ToDo list for now. That's almost exactly the question i wanted to ask - what happens when several pre- or post- operation plug-ins affect the same entry? For example, the memberOf (or DNA) plug-in changes the memberOf attribute of an entry. Is this change of memberOf attribute considered as an entryUSN increment or not? Is there some general rule (for example, for pre- plugins the entryUSN is increased and for post- it is not...)? @+ From nhosoi at redhat.com Tue Jul 21 21:38:10 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 21 Jul 2009 14:38:10 -0700 Subject: [389-devel] Entry USN (additional changes) In-Reply-To: <1601b8650907211427u34526b2bu8001ac3c37c66289@mail.gmail.com> References: <4A64D9CF.5090204@redhat.com> <4A662047.6040008@redhat.com> <1601b8650907211427u34526b2bu8001ac3c37c66289@mail.gmail.com> Message-ID: <4A663542.9010603@redhat.com> Hi Andrey, On 07/21/2009 02:27 PM, Andrey Ivanov wrote: > Hi, > > >> Nathan also pointed out several typos as well as an issue of internal >> deletion. Currently, if the delete is initiated internally, the entry is >> not converted to a tombstone unless the backend is replicated. I'm adding >> this issue to ToDo list for now. >> > > That's almost exactly the question i wanted to ask - what happens when > several pre- or post- operation plug-ins affect the same entry? For > example, the memberOf (or DNA) plug-in changes the memberOf attribute > of an entry. Is this change of memberOf attribute considered as an > entryUSN increment or not? > Is there some general rule (for example, for pre- plugins the entryUSN > is increased and for post- it is not...)? > Assigning USN is implemented as backend preop callbacks (see usn.c). They are called just before updating the database. That is, every time the entry is updated regardless of the updater, USN is counted up. That being said, it could be considered as one operation from the client point of view, it could be internally multiple updates. In such case, USN could be counted up by more than one with "one operation". Converting an entry to a tombstone is an exception. It's implemented as a pure preop callback, which is only called when the updater is external. Thanks! --noriko > @+ > > -- > 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 Jul 21 23:15:23 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 21 Jul 2009 16:15:23 -0700 Subject: [389-devel] Entry USN (pushed to master) In-Reply-To: <4A662047.6040008@redhat.com> References: <4A64D9CF.5090204@redhat.com> <4A662047.6040008@redhat.com> Message-ID: <4A664C0B.3070404@redhat.com> Reviewed by Nathan (Thank you!!) Pushed to master. --noriko On 07/21/2009 01:08 PM, Noriko Hosoi wrote: > Regarding the first question from Andrey: > > The USNs seem to be unique within a suffix/backend. Should we enable > the uniqueness plug-in for them? If not can we be sure that a manual > change of entryUSN will not interfere with the correct functioning > of the plug-in? > > Nathan suggested to set SLAPI_ATTR_FLAG_NOUSERMOD to the attribute > entryusn as follows. > > diff --git a/ldap/servers/slapd/back-ldbm/init.c > b/ldap/servers/slapd/back-ldbm/ > index a4ff79c..be9c114 100644 > --- a/ldap/servers/slapd/back-ldbm/init.c > +++ b/ldap/servers/slapd/back-ldbm/init.c > @@ -86,7 +86,7 @@ ldbm_back_add_schema( Slapi_PBlock *pb ) > rc |= add_ldbm_internal_attr_syntax( "entryusn", > LDBM_ENTRYUSN_OID, INTEGER_SYNTAX_OID, > INTFIRSTCOMPMATCH > - SLAPI_ATTR_FLAG_SINGLE ); > + > SLAPI_ATTR_FLAG_SINGLE|SLAPI_ATTR_FLAG_NOUSERMOD ); > return rc; > } > > The flag nicely prevents the manual update on EntryUSN. > > ldapmodify -D "cn=Directory Manager" -w /password/ > dn: uid=tuserX,dc=example,dc=com > changetype: modify > replace: entryusn > entryusn: 100 > > modifying entry uid=tuserX,dc=example,dc=com > ldap_modify: DSA is unwilling to perform > ldap_modify: additional info: no modifiable attributes specified > > Nathan also pointed out several typos as well as an issue of internal > deletion. Currently, if the delete is initiated internally, the entry > is not converted to a tombstone unless the backend is replicated. I'm > adding this issue to ToDo list for now. > Attached patch includes the above diff and typo fixes. > > Thanks so much to Nathan for his reviews and suggestions. > --noriko > > Noriko Hosoi wrote: >> First cut for implementing Entry USN. >> See http://directory.fedoraproject.org/wiki/Entry_USN for the design >> details. >> This change includes a bug fix for "db2ldif -r"; event queue system >> was not >> shutdown before the plugins are closed, which could have crashed the >> command >> line utility. >> >> Thanks, >> --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 nkinder at redhat.com Mon Jul 27 22:21:40 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 27 Jul 2009 15:21:40 -0700 Subject: [389-devel] Please Review: Change aci attribute syntax to Directory String Message-ID: <4A6E2874.7030209@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Change-aci-syntax-to-Directory-String.patch URL: From rmeggins at redhat.com Mon Jul 27 22:23:43 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 27 Jul 2009 16:23:43 -0600 Subject: [389-devel] Please Review: Change aci attribute syntax to Directory String In-Reply-To: <4A6E2874.7030209@redhat.com> References: <4A6E2874.7030209@redhat.com> Message-ID: <4A6E28EF.9010101@redhat.com> Nathan Kinder wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel looks good -------------- 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 Mon Jul 27 22:35:50 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 27 Jul 2009 15:35:50 -0700 Subject: [389-devel] Please Review: Change aci attribute syntax to Directory String In-Reply-To: <4A6E28EF.9010101@redhat.com> References: <4A6E2874.7030209@redhat.com> <4A6E28EF.9010101@redhat.com> Message-ID: <4A6E2BC6.8000400@redhat.com> On 07/27/2009 03:23 PM, Rich Megginson wrote: > Nathan Kinder wrote: >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > looks good 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at stardoll.com Tue Jul 28 09:38:36 2009 From: peter at stardoll.com (=?UTF-8?Q?Peter_Sandstr=C3=B6m?=) Date: Tue, 28 Jul 2009 11:38:36 +0200 Subject: [389-devel] Bug in windows replication Message-ID: <76dee6640907280238x6061eef9y6c93cc9fe0e3f23@mail.gmail.com> The entry is added before the check for wierd values, causing it to fail. The following patch fixes it. diff -ru fedora-ds-base-1.2.0-orig/ldap/servers/plugins/replication/windows_connection.c fedora-ds-base-1.2.0/ldap/servers/plugins/replication/windows_connection.c --- fedora-ds-base-1.2.0-orig/ldap/servers/plugins/replication/windows_connection.c 2008-12-05 17:41:52.000000000 -0500 +++ fedora-ds-base-1.2.0/ldap/servers/plugins/replication/windows_connection.c 2009-07-28 05:13:40.564546527 -0400 @@ -542,7 +542,6 @@ for ( a = ldap_first_attribute( ld, msg, &ber ); a!=NULL; a=ldap_next_attribute( ld, msg, ber ) ) { struct berval ** aVal = ldap_get_values_len( ld, msg, a); - slapi_entry_add_values(rawentry, a, aVal); if (0 == strcasecmp(a,"dnsRecord") || 0 == strcasecmp(a,"dnsproperty") || 0 == strcasecmp(a,"dscorepropagationdata")) @@ -556,6 +555,7 @@ ; } else { + slapi_entry_add_values(rawentry, a, aVal); if (attrsonly) { slapi_entry_add_value(e, a, (Slapi_Value *)NULL); -- Peter Sandstr?m Head of Operations, Stardoll AB phone: +46 (0)70 456 05 28 e-mail: peter at stardoll.com | stardoll: pj0tr mail/visit: Hudiksvallsgatan 8, 113 30 Stockholm, Sweden www.stardoll.com - Fame, fashion and friends From hyc at symas.com Tue Jul 28 18:58:23 2009 From: hyc at symas.com (Howard Chu) Date: Tue, 28 Jul 2009 11:58:23 -0700 Subject: [389-devel] Re: Please Review: Change aci attribute syntax to Directory String (Nathan Kinder) In-Reply-To: <20090728160054.2EFEB61BAF6@hormel.redhat.com> References: <20090728160054.2EFEB61BAF6@hormel.redhat.com> Message-ID: <4A6F4A4F.5080205@symas.com> > The aci attribute is currently defined with a syntax of IA5 String. > This syntax only allows 7-bit characters. Now that the server has > support for syntax validation, this would prevent one from using > international characters in aci rules. This patch defines the aci > attribute with the Directory String syntax, which allows any valid > UTF8 character. Y'know, LDAP/X.500 requires that existing schema items must never be changed once they're in use. When you want to change something like this, usually you must define a new attributeType with a new OID for the purpose. Probably not so important given the history of schema checking in this code, but an fyi... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From rmeggins at redhat.com Tue Jul 28 19:47:15 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 28 Jul 2009 13:47:15 -0600 Subject: [389-devel] Re: Please Review: Change aci attribute syntax to Directory String (Nathan Kinder) In-Reply-To: <4A6F4A4F.5080205@symas.com> References: <20090728160054.2EFEB61BAF6@hormel.redhat.com> <4A6F4A4F.5080205@symas.com> Message-ID: <4A6F55C3.2060705@redhat.com> Howard Chu wrote: >> The aci attribute is currently defined with a syntax of IA5 String. >> This syntax only allows 7-bit characters. Now that the server has >> support for syntax validation, this would prevent one from using >> international characters in aci rules. This patch defines the aci >> attribute with the Directory String syntax, which allows any valid >> UTF8 character. > > Y'know, LDAP/X.500 requires that existing schema items must never be > changed once they're in use. When you want to change something like > this, usually you must define a new attributeType with a new OID for > the purpose. Probably not so important given the history of schema > checking in this code, but an fyi... > Thanks. Yes, that was definitely a consideration, and we thought about this quite a bit before making this decision. We only chose this route because it was the least evil. -------------- 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 Jul 28 19:57:42 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 28 Jul 2009 12:57:42 -0700 Subject: [389-devel] Re: Please Review: Change aci attribute syntax to Directory String (Nathan Kinder) In-Reply-To: <4A6F4A4F.5080205@symas.com> References: <20090728160054.2EFEB61BAF6@hormel.redhat.com> <4A6F4A4F.5080205@symas.com> Message-ID: <4A6F5836.5020406@redhat.com> On 07/28/2009 11:58 AM, Howard Chu wrote: >> The aci attribute is currently defined with a syntax of IA5 String. >> This syntax only allows 7-bit characters. Now that the server has >> support for syntax validation, this would prevent one from using >> international characters in aci rules. This patch defines the aci >> attribute with the Directory String syntax, which allows any valid >> UTF8 character. > > Y'know, LDAP/X.500 requires that existing schema items must never be > changed once they're in use. When you want to change something like > this, usually you must define a new attributeType with a new OID for > the purpose. Probably not so important given the history of schema > checking in this code, but an fyi... > Thanks for the heads up. In this case, there are likely people with aci values out in the wild that are not 7-bit clean, despite the fact that the attribute is defined as an IA5 String. These aci values have worked just fine since we only recently added syntax validation when adding attribute values. Not changing the syntax of the aci attribute to Directory String would break existing deployments that have been depending on this functionality, hence the decision to modify the existing definition. From rmeggins at redhat.com Wed Jul 29 17:21:45 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 29 Jul 2009 11:21:45 -0600 Subject: [389-devel] Please review: LDAP Dereference Control support Message-ID: <4A708529.9060802@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Dereference-support-small.patch Type: text/x-patch Size: 44423 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 rmeggins at redhat.com Wed Jul 29 21:36:37 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 29 Jul 2009 15:36:37 -0600 Subject: [389-devel] Bug in windows replication In-Reply-To: <76dee6640907280238x6061eef9y6c93cc9fe0e3f23@mail.gmail.com> References: <76dee6640907280238x6061eef9y6c93cc9fe0e3f23@mail.gmail.com> Message-ID: <4A70C0E5.9070906@redhat.com> Peter Sandstr?m wrote: > The entry is added before the check for wierd values, causing it to fail. > Can you provide some information about how to reproduce the problem? > The following patch fixes it. > > diff -ru fedora-ds-base-1.2.0-orig/ldap/servers/plugins/replication/windows_connection.c > fedora-ds-base-1.2.0/ldap/servers/plugins/replication/windows_connection.c > --- fedora-ds-base-1.2.0-orig/ldap/servers/plugins/replication/windows_connection.c > 2008-12-05 17:41:52.000000000 -0500 > +++ fedora-ds-base-1.2.0/ldap/servers/plugins/replication/windows_connection.c > 2009-07-28 05:13:40.564546527 -0400 > @@ -542,7 +542,6 @@ > for ( a = ldap_first_attribute( ld, msg, &ber ); a!=NULL; > a=ldap_next_attribute( ld, msg, ber ) ) > { > struct berval ** aVal = ldap_get_values_len( ld, msg, a); > - slapi_entry_add_values(rawentry, a, aVal); > > if (0 == strcasecmp(a,"dnsRecord") || 0 == > strcasecmp(a,"dnsproperty") || > 0 == strcasecmp(a,"dscorepropagationdata")) > @@ -556,6 +555,7 @@ > ; > } else > { > + slapi_entry_add_values(rawentry, a, aVal); > if (attrsonly) > { > slapi_entry_add_value(e, a, > (Slapi_Value *)NULL); > > > -------------- 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 Thu Jul 30 00:28:42 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 29 Jul 2009 17:28:42 -0700 Subject: [389-devel] Please review: LDAP Dereference Control support In-Reply-To: <4A708529.9060802@redhat.com> References: <4A708529.9060802@redhat.com> Message-ID: <4A70E93A.2090004@redhat.com> On 07/29/2009 10:21 AM, Rich Megginson wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > Looks good to me. --noriko -------------- 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 Thu Jul 30 01:32:16 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 29 Jul 2009 18:32:16 -0700 Subject: [389-devel] Please review: Apply SYNTAX_DN to Name And Optional UID Message-ID: <4A70F820.2020807@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Apply-SYNTAX_DN-to-Name-And-Optional-UID.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 nhosoi at redhat.com Thu Jul 30 02:09:40 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 29 Jul 2009 19:09:40 -0700 Subject: [389-devel] Commit: Apply SYNTAX_DN to Name And Optional UID In-Reply-To: <4A70F820.2020807@redhat.com> References: <4A70F820.2020807@redhat.com> Message-ID: <4A7100E4.7030006@redhat.com> Thanks to Nathan for his review and comments. Pushed to master. $ git merge acl Updating f3719fb..ff6d5df Fast forward ldap/servers/plugins/syntaxes/nameoptuid.c | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) $ git push Counting objects: 13, done. Delta compression using 4 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 727 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git f3719fb..ff6d5df master -> master Noriko Hosoi wrote: > > ------------------------------------------------------------------------ > > -- > 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: 3237 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Jul 30 02:19:51 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 29 Jul 2009 20:19:51 -0600 Subject: [389-devel] Please review: LDAP Dereference Control support In-Reply-To: <4A70E93A.2090004@redhat.com> References: <4A708529.9060802@redhat.com> <4A70E93A.2090004@redhat.com> Message-ID: <4A710347.4050406@redhat.com> Noriko Hosoi wrote: > On 07/29/2009 10:21 AM, Rich Megginson wrote: >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > Looks good to me. 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: From samuel.graenacher at ch.sauter-bc.com Thu Jul 30 02:08:50 2009 From: samuel.graenacher at ch.sauter-bc.com (Samuel Graenacher) Date: Thu, 30 Jul 2009 04:08:50 +0200 Subject: [389-devel] AUTO: Samuel Graenacher is out of the office. (returning 08/10/2009) Message-ID: I am out of the office until 08/10/2009. For very urgent matters you may contact Mr. Andre Krutein or Mr. Dominik Baumeler. Otherwise I will respond soon after I get back. Note: This is an automated response to your message "Re: [389-devel] Please review: LDAP Dereference Control support" sent on 30.07.2009 02:28:42. This is the only notification you will receive while this person is away. From nhosoi at redhat.com Thu Jul 30 17:51:11 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 30 Jul 2009 10:51:11 -0700 Subject: [389-devel] Please review: [Bug 514770] GER, Paged Results: remove per-entry response control In-Reply-To: References: Message-ID: <4A71DD8F.8010701@redhat.com> Summary: GER, Paged Results: remove per-entry response control https://bugzilla.redhat.com/show_bug.cgi?id=514770 Description of problem: Currently, Simple Paged Results and GER returns response control per-entry. Since per entry-response controls (except for persistent search EntryChange controls) are ignored by the ldapsearch client, we are getting rid of the unnecessary write_controls calls for Simple Paged Results and GER [Proposed Fix] Created an attachment (id=355712) --> (https://bugzilla.redhat.com/attachment.cgi?id=355712) git patch file for result.c File: ldap/servers/slapd/result.c Fix description: Getting rid of the unnecessary write_controls calls for GER and Simple Paged Results. Note: both GER and Simple Paged Results add its control to the result controls maintained in the "operation" and they are sent to the client via send_ldap_result. -------------- 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 Thu Jul 30 18:19:32 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 30 Jul 2009 11:19:32 -0700 Subject: [389-devel] Please review: [Bug 514770] GER, Paged Results: remove per-entry response control In-Reply-To: <4A71DD8F.8010701@redhat.com> References: <4A71DD8F.8010701@redhat.com> Message-ID: <4A71E434.9030506@redhat.com> On 07/30/2009 10:51 AM, Noriko Hosoi wrote: > Summary: GER, Paged Results: remove per-entry response control > > https://bugzilla.redhat.com/show_bug.cgi?id=514770 > > Description of problem: > Currently, Simple Paged Results and GER returns response control > per-entry. > Since per entry-response controls (except for persistent search > EntryChange > controls) are ignored by the ldapsearch client, we are getting rid of the > unnecessary write_controls calls for Simple Paged Results and GER > > [Proposed Fix] > Created an attachment (id=355712) > --> (https://bugzilla.redhat.com/attachment.cgi?id=355712) > git patch file for result.c > > File: ldap/servers/slapd/result.c > > Fix description: Getting rid of the unnecessary write_controls calls > for GER > and Simple Paged Results. > > Note: both GER and Simple Paged Results add its control to the result > controls > maintained in the "operation" and they are sent to the client via > send_ldap_result. 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 nkinder at redhat.com Thu Jul 30 22:37:52 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 30 Jul 2009 15:37:52 -0700 Subject: [389-devel] Please Review: (514824) Multi-macro ACIs can cause double free if macro attribute does not exist Message-ID: <4A7220C0.6030507@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=514824 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Bug-514824-Fix-double-free-in-macro-ACI-code.patch URL: From nkinder at redhat.com Fri Jul 31 00:10:39 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 30 Jul 2009 17:10:39 -0700 Subject: [389-devel] Please Review: (514824) Multi-macro ACIs can cause double free if macro attribute does not exist In-Reply-To: <4A7220C0.6030507@redhat.com> References: <4A7220C0.6030507@redhat.com> Message-ID: <4A72367F.7000204@redhat.com> On 07/30/2009 03:37 PM, Nathan Kinder wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=514824 > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > Here's a new patch that addresses some issues Noriko brought up. The list "a" was being set to NULL when we found an attribute match for a macro, but this is no longer necessary now that we reset "a" to NULL when the memory is handed off to the working_list (which covers both the cases of finding/not finding the attribute). We were also accessing element 0 of list "a" right after handing the memory off to the working_list, but we weren't checking if "a" was NULL first. I don't believe that "a" could be NULL at this point, but it's safest to check first in case there is some corner case we're not considering. -NGK -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Bug-514824-Fix-double-free-in-macro-ACI-code.patch URL: From nhosoi at redhat.com Fri Jul 31 00:15:03 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 30 Jul 2009 17:15:03 -0700 Subject: [389-devel] Please Review: (514824) Multi-macro ACIs can cause double free if macro attribute does not exist In-Reply-To: <4A72367F.7000204@redhat.com> References: <4A7220C0.6030507@redhat.com> <4A72367F.7000204@redhat.com> Message-ID: <4A723787.1070807@redhat.com> On 07/30/2009 05:10 PM, Nathan Kinder wrote: > On 07/30/2009 03:37 PM, Nathan Kinder wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=514824 >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > Here's a new patch that addresses some issues Noriko brought up. > > The list "a" was being set to NULL when we found an attribute match for a > macro, but this is no longer necessary now that we reset "a" to NULL > when the > memory is handed off to the working_list (which covers both the cases of > finding/not finding the attribute). > > We were also accessing element 0 of list "a" right after handing the > memory off > to the working_list, but we weren't checking if "a" was NULL first. I > don't > believe that "a" could be NULL at this point, but it's safest to check > first in > case there is some corner case we're not considering. > > -NGK > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > Looks good. Thanks for considering my questions! --noriko -------------- 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 Fri Jul 31 00:56:41 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 30 Jul 2009 17:56:41 -0700 Subject: [389-devel] Please Review: (514824) Multi-macro ACIs can cause double free if macro attribute does not exist In-Reply-To: <4A723787.1070807@redhat.com> References: <4A7220C0.6030507@redhat.com> <4A72367F.7000204@redhat.com> <4A723787.1070807@redhat.com> Message-ID: <4A724149.9060300@redhat.com> On 07/30/2009 05:15 PM, Noriko Hosoi wrote: > On 07/30/2009 05:10 PM, Nathan Kinder wrote: >> On 07/30/2009 03:37 PM, Nathan Kinder wrote: >>> https://bugzilla.redhat.com/show_bug.cgi?id=514824 >>> ------------------------------------------------------------------------ >>> >>> -- >>> 389-devel mailing list >>> 389-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >> Here's a new patch that addresses some issues Noriko brought up. >> >> The list "a" was being set to NULL when we found an attribute match for a >> macro, but this is no longer necessary now that we reset "a" to NULL >> when the >> memory is handed off to the working_list (which covers both the cases of >> finding/not finding the attribute). >> >> We were also accessing element 0 of list "a" right after handing the >> memory off >> to the working_list, but we weren't checking if "a" was NULL first. >> I don't >> believe that "a" could be NULL at this point, but it's safest to >> check first in >> case there is some corner case we're not considering. >> >> -NGK >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > Looks good. Thanks for considering my questions! Pushed to master. Thanks for the review! > --noriko > ------------------------------------------------------------------------ > > -- > 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 nkinder at redhat.com Fri Jul 31 02:21:01 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 30 Jul 2009 19:21:01 -0700 Subject: [389-devel] Please Review: (514848) Make selfwrite ACI keyword with with Name And Optional UID syntax attributes Message-ID: <4A72550D.4000800@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=514848 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Bug-514848-Make-selfwrite-ACI-keyword-with-with-Nam.patch URL: From rmeggins at redhat.com Fri Jul 31 02:26:58 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 30 Jul 2009 20:26:58 -0600 Subject: [389-devel] Please Review: (514848) Make selfwrite ACI keyword with with Name And Optional UID syntax attributes In-Reply-To: <4A72550D.4000800@redhat.com> References: <4A72550D.4000800@redhat.com> Message-ID: <4A725672.6050000@redhat.com> Nathan Kinder wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=514848 > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel ack -------------- 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 Fri Jul 31 02:39:27 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 30 Jul 2009 19:39:27 -0700 Subject: [389-devel] Please Review: (514848) Make selfwrite ACI keyword with with Name And Optional UID syntax attributes In-Reply-To: <4A725672.6050000@redhat.com> References: <4A72550D.4000800@redhat.com> <4A725672.6050000@redhat.com> Message-ID: <4A72595F.5010005@redhat.com> On 07/30/2009 07:26 PM, Rich Megginson wrote: > Nathan Kinder wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=514848 >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > ack 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhosoi at redhat.com Fri Jul 31 18:59:54 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 31 Jul 2009 11:59:54 -0700 Subject: [389-devel] Please review: [PATCH] GroupOfUniqueNames in template.ldif must have uniqueMember Message-ID: <4A733F2A.60309@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-GroupOfUniqueNames-in-template.ldif-must-have-unique.patch Type: text/x-patch Size: 2182 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 nhosoi at redhat.com Fri Jul 31 20:44:44 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 31 Jul 2009 13:44:44 -0700 Subject: [389-devel] Commit: [PATCH] GroupOfUniqueNames in template.ldif must have uniqueMember In-Reply-To: <4A733F2A.60309@redhat.com> References: <4A733F2A.60309@redhat.com> Message-ID: <4A7357BC.4060302@redhat.com> Thanks to Nathan for the review. I added some comment to template.ldif and pushed to master. $ git merge work Updating dd31da5..2d0bcea Fast forward ldap/admin/src/scripts/dsorgentries.map.in | 1 + ldap/ldif/template.ldif | 12 ++++++++++++ 2 files changed, 13 insertions(+), 0 deletions(-) $ git push Counting objects: 17, done. Delta compression using 4 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (9/9), 1.16 KiB, done. Total 9 (delta 7), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git dd31da5..2d0bcea master -> master On 07/31/2009 11:59 AM, Noriko Hosoi 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 -------------- 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 Fri Jul 31 22:16:07 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 31 Jul 2009 15:16:07 -0700 Subject: [389-devel] Please Review: (514955) Don't replicate DNA generation mod Message-ID: <4A736D27.5050503@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=514955 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Bug-514955-Don-t-replicate-DNA-generation-modify-o.patch URL: