Re: [389-devel] Git rights for QE team
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/23/2015 01:38 AM, Simon Pichugin wrote: > Hi Nathan, Hi Mark, Hi team, > > as I know, we've decided to make me "gatekeeper" of QE team for > managing lib389 and DS git repos. > > Can you please update the status of this situation? > > Also, there is two tickets with new reviewed testcases, that need > to be pushed. Can you please help me with that? Or if I'll get the > rights soon, I do it by myself. :) I have added you to the 'git389test' group in the Fedora Account System. This should give you push/commit access. If there is a problem, let us know. Thanks, - -NGK > > https://fedorahosted.org/389/ticket/47957 > https://fedorahosted.org/389/ticket/48264 > > Thanks, Simon > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWArfNAAoJEJa+6E7Ri+EVwTUH/037BF/IPD9cDsYizVi2t3vA yUTbqjZ8athkCxEeGBe+qWQF83AjEkwHuBGd/xBCz/zDgwkrb0fle3IzdzSEMbqq IUqBny7skPvazxN0BbKzqU0uakWz3y8NJ46GB/4Z7VbXbZiHlFSNZ8Hy/fnX7JIK DGfTG9rGrNkjOcycK6BCH1zQerWgu5GXBxLLdtJasaFF6SwM1kZ+2E2WS9e3l/mw AH6O9t4Jn/jQIGZSZSdEzK8qc2MbJqn7DqBOTCwrvZ4e/A4NnCUd00HPQcuwVwP2 B9tkt9y7dsPi4qLqoL7Cm2+7oT5xsynBmrD1BCMUKw4Ao1pdJ1r/93PD1JZoLd0= =boBh -END PGP SIGNATURE- -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: Ticket #47892 coverity defects found in 1.3.3.1
On 09/12/2014 12:59 PM, Rich Megginson wrote: https://fedorahosted.org/389/attachment/ticket/47892/0001-Ticket-47892-coverity-defects-found-in-1.3.3.1.patch ACK. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: Ticket #47492 - PassSync removes User must change password flag on the Windows side
On 04/03/2014 08:13 PM, Rich Megginson wrote: https://fedorahosted.org/389/attachment/ticket/47492/0001-Ticket-47492-PassSync-removes-User-must-change-passw.3.patch Ack -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (47752) Don't add unhashed password mod if we don't have an unhashed value
https://fedorahosted.org/389/ticket/47752 https://fedorahosted.org/389/attachment/ticket/47752/0001-Ticket-47752-Don-t-add-unhashed-password-mod-if-we-d.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] plugin problem using slapi_entry_attr_find
On 01/16/2014 03:14 PM, Deas, Jim wrote: Rich, Thanks. I actually did have the address of operator on the code. Both the init and config are defining only a couple of specific functions (start_fn, pre_results_fn,pre_abandon_fn) one function defined for each. The one I am testing is preop_results() which does trigger, works as you suggested below, but crashes when adding a call to slapi_entry_attr_find() for many but not all remote inquiries. In the code you shared, you are setting e with this call: slapi_pblock_get( pb, SLAPI_SEARCH_ATTRS, e) The issue here is that e is a Slapi_Entry, but SLAPI_SEARCH_ATTRS doesn't retreive a Slapi_Entry from the pblock. This means e is incorrect at this point (it will likely have bad pointer values if you look into it in gdb). When you call slapi_entry_attr_find(), it is likely trying to dereference some of these bad pointer values, which leads to the crash. You need to pass a valid Slapi_Entry to this function (if you even need this function). What exactly are you trying to have your plug-in do? Thanks, -NGK Perhaps I am going at this all wrong. What sequence should I call to get a multivariable attribute? In this case a list of attribute ‘memberUid’ while rejecting preop_results not directed at returning Group information? JD *From:*389-devel-boun...@lists.fedoraproject.org [mailto:389-devel-boun...@lists.fedoraproject.org] *On Behalf Of *Rich Megginson *Sent:* Thursday, January 16, 2014 2:25 PM *To:* 389 Directory server developer discussion. *Subject:* Re: [389-devel] plugin problem using slapi_entry_attr_find Another bug in your code. The argument for SLAPI_SEARCH_ATTRS should be the address of a char **.e.g. { char **attrs; int ii = 0; ... if (slapi_pblock_get( pb, SLAPI_SEARCH_ATTRS, attrs) !=0 )return (-1); for (ii = 0; attrs attrs[ii]; ++ii) { slapi_log_error(SLAPI_LOG_PLUGIN, my plugin, search attr %d is %s\n, ii, attrs[ii]); } ... In your plugin entry and in your plugin config you specify which types of operations (bind, search, add, etc.) your plugin will handle. E.g. a SLAPI_PLUGIN_PRE_BIND_FN will be called at the pre-operation stage of a BIND operation. Each type of plugin will have possibly different pblock parameters available. So, for example, if you use the same function as both a bind preop and a search preop - when called as a bind preop, the SLAPI_SEARCH_ATTRS will not be available. If you want to use the same function for different op types, declare different functions for each op type, then call your common function with the op type, like this: int bind_preop(Slapi_PBlock *pb) { return common_function(SLAPI_PLUGIN_PRE_BIND_FN, pb); } int search_preop(Slapi_PBlock *pb) { return common_function(SLAPI_PLUGIN_PRE_SEARCH_FN, pb); } ... int common_function(int type, Slapi_PBlock *pb) { ... if (type == SLAPI_PLUGIN_PRE_BIND_FN) { do some bind specific action } else if (type == SLAPI_PLUGIN_PRE_SEARCH_FN) { do some search specific action } ... On 01/16/2014 03:02 PM, Deas, Jim wrote: On further review it appears that the line in question will crash Dirsrv on some request from PAM or even 389-Console but not when searching groups via ldapsearch Should there be a statement that determines what type of query triggered the preop_result so I know if it’s proper to look for attributes? *From:*389-devel-boun...@lists.fedoraproject.org mailto:389-devel-boun...@lists.fedoraproject.org [mailto:389-devel-boun...@lists.fedoraproject.org] *On Behalf Of *Rich Megginson *Sent:* Thursday, January 16, 2014 11:29 AM *To:* 389 Directory server developer discussion. *Subject:* Re: [389-devel] plugin problem using slapi_entry_attr_find On 01/16/2014 11:39 AM, Deas, Jim wrote: My bet, a rookie mistake. Am I forgetting to init a pointer etc??? Adding the line surrounded by ** in this routine makes dirsrv unstable and crashes it after a few queries. /* Registered preop_result routine */ int gnest_preop_results( Slapi_PBlock *pb){ Slapi_Entry *e; Slapi_Attr **a; This should be Slapi_Attr *a; If (slapi_pblock_get( pb, SLAPI_SEARCH_ATTRS, e) !=0 )return (-1); /*This line makes the server unstable and crashes it after one or two queries / If(slapi_entry_attr_find(e, “memberUid”,a) == 0) slapi_log_error(SLAPI_LOG_PLUGIN, “gnest preop”,”memberUid found in record); /**/
[389-devel] Please Review: (47525) Allow memberOf to use an alternate config area
https://fedorahosted.org/389/ticket/47525 https://fedorahosted.org/389/attachment/ticket/47525/0001-Ticket-47525-Don-t-modify-preop-entry-in-memberOf-co.patch The previous fix for this issue was causing a crash in one of the in-tree tests. This patch addresses the crash. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please Review: (47525) Allow memberOf to use an alternate config area
On 12/12/2013 04:08 PM, Nathan Kinder wrote: https://fedorahosted.org/389/ticket/47525 https://fedorahosted.org/389/attachment/ticket/47525/0001-Ticket-47525-Don-t-modify-preop-entry-in-memberOf-co.patch The previous fix for this issue was causing a crash in one of the in-tree tests. This patch addresses the crash. Noriko pointed out a problem in the previous patch. A new version of the patch has been attached to the ticket for review: https://fedorahosted.org/389/attachment/ticket/47525/0001-Ticket-47525-Don-t-modify-preop-entry-in-memberOf-co.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (Ticket 47565) upgrade to 1.3.2.2 causes error with Content Sync plugin
https://fedorahosted.org/389/ticket/47565 https://fedorahosted.org/389/attachment/ticket/47565/0001-Ticket-47565-Content-Sync-update-file-needs-extensib.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] 389-ds-base_Debian_Wheezy - Build # 90 - Failure!
I just pushed the following patch under the trivial fix rule to address these warnings. This should make the Jenkins jobs green again. https://fedorahosted.org/389/attachment/ticket/47569/0001-Ticket-47569-Fix-build-warnings.patch On 10/22/2013 05:32 PM, nkin...@redhat.com wrote: 389-ds-base_Debian_Wheezy - Build # 90 - Failure: See attached build log for details. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (Ticket 47513) tmpfiles.d references /var/lock when they should reference /run/lock
https://fedorahosted.org/389/ticket/47513 https://fedorahosted.org/389/attachment/ticket/47513/0001-Ticket-47513-tmpfiles.d-references-var-lock-when-the.2.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] switch to F19 for autogen?
On 10/09/2013 01:21 PM, Rich Megginson wrote: In the interest of reducing the autotool file churn, is everyone ok with switching to using F19 to run autogen? Ack. If we want to enforce that for master, we could update the version checks in autogen.sh to require the F19 versions as a minimum. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Jenkins changes
Hi, I made some modifications to our Jenkins jobs which affect the e-mails that are sent to this list when encountering a build failure. Last week, I had changed the e-mails to include the entire build logs for failed builds as a convenience (no need to go to the Jenkins URL to see why the build failed). This works fine when the build fails early, but the build logs end up being too large for the mailing list in most other cases. This was causing the mailing list maximum message size limit to be hit, which holds the messages for a moderator. The jobs will now only include the last 100 lines of the build log for failed builds. This should be enough context to troubleshoot the problem in most cases. A link to the build URL in Jenkins will be included in case you need to access the full build log. Thanks, -NGK -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (Ticket 47539) Disabling DNA plug-in throws error 53
https://fedorahosted.org/389/ticket/47539 https://fedorahosted.org/389/attachment/ticket/47539/0001-Ticket-47539-Disabling-DNA-plug-in-throws-error-53.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: #47388: [RFE] Support 'Content Synchronization Operation' (SyncRepl)
On 09/26/2013 07:22 AM, Ludwig Krispenz wrote: Hi, I published the latest version of the patch: https://fedorahosted.org/389/attachment/ticket/47388/0001-Ticket-47388-RFE-to-imnplement-RFC4533.patch It fixes the issues raised with the previous versions and I also did check memory leaks with valgrind, I think the changes to the core server are minimal, all the stuff is in the plugin, so even if there is a need for more tests, especially stress tests, I would like to commit to master and then handle new issues found as bug fixes to the feature. In general, it looks good. We should add a plug-in dependency on the retro changelog plug-in in the dse.ldif template and the update file. I'm OK if you want to deal with this in another ticket, though it might just be simple to add into this patch. Why do we have an empty sync_handle_cnum_result() function? Now for some real nit-picky stuff... ;) There's a typo in a comment in sync_persist_initialize(). It has persisten instead of persistent. There are a few tab vs. space issues in the definition of SyncRequest in sync.h. There are also a tab vs. space issues at sync_init.c:111, sync_init.c:175, sync_persist.c:269, sync_persist.c:665, sync_util.c:367, and sync_util.c:332. You should add braces around the body of the if/else statements at sync_persist.c:369, sync_persist.c:470, sync_persist.c:646, sync_refresh.c:197, sync_refresh.c:253, sync_refresh.c:337, sync_refresh.c:356, sync_refresh.c:358, sync_util.c:251, sync_util.c:544, sync_util.c:608, sync_util.c:682, and result.c:294. If you address the above issues, I'm OK with you pushing it to the repo. Thanks, -NGK Regards, Ludwig On 08/30/2013 05:00 PM, Nathan Kinder wrote: On 08/30/2013 05:06 AM, Ludwig Krispenz wrote: Hello, I completed an implementation of rfc 4533 as a plugin in RHDS, ticket #47388 https://fedorahosted.org/389/ticket/47388 https://fedorahosted.org/389/attachment/ticket/47388/0001-Implement-RFC-4533-as-plugin-version-1.patch a document describing the implentation can be found here: http://port389.org/wiki/Content_synchronization_plugin Please review the changes and the design doc. There are still some issues, eg valgrind reports some mem leaks I still need to fix, but I wanted to get this out and get some feedback. The plugin code itself could be committed and further improved without doing harm, but there are a few changes affecting the core server, so pleas look at least for them. I'm still reviewing the new code, but I believe that you accidentally removed the whoami plug-in from Makefile.am. Thanks, -NGK Thanks, Ludwig -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] 389-ds-base_Debian_Wheezy - Build # 46 - Fixed!
FYI - Please ignore these failures, as I manually triggered them to fail in my Jenkins build environment. As you can see from these reports, we now have a Jenkins system set up to perform Continuous Integration builds of the main 389 DS code (389-ds-base) on Debian 7.1 (Wheezy). These builds will be triggered whenever there is a new commit in the 'master' branch of our git repository. Thanks, -NGK On 09/25/2013 11:56 AM, nkin...@redhat.com wrote: 389-ds-base_Debian_Wheezy - Build # 46 - Fixed: See attached build log for details. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (ticket 449) Possible to set invalid macros in Macro ACIs
https://fedorahosted.org/389/ticket/449 https://fedorahosted.org/389/attachment/ticket/449/0001-Ticket-449-Allow-macro-aci-keywords-to-be-case-insen.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: another compiler warning for F20 admin
ACK. On 08/16/2013 09:55 AM, Rich Megginson wrote: -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (Ticket 47467) Improve Add CRL/CKL dialog and errors
https://fedorahosted.org/389/ticket/47467 These patches improve the Add CRL/CKL Console dialog. Changes were needed in Admin Server for the security CGI error messages, IDM Console Framework for the dialog improvements, and Admin Console for the online help page. I've included screenshots of the new UI. Admin Server: https://fedorahosted.org/389/attachment/ticket/47467/0001-Ticket-47467-Improve-CRL-import-error-messages.patch IDM Console Framework: https://fedorahosted.org/389/attachment/ticket/47467/0001-Ticket-47467-Improve-CRL-import-dialog-text.patch Admin Console: https://fedorahosted.org/389/attachment/ticket/47467/0001-Ticket-47467-Improve-online-help-for-Add-CRL-dialog.patch Screenshots: https://fedorahosted.org/389/attachment/ticket/47467/console-crlpath-error.png https://fedorahosted.org/389/attachment/ticket/47467/cosole-crlformat-error.png https://fedorahosted.org/389/attachment/ticket/47467/console-crldialog.png Thanks, -NGK -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (Ticket 362) Directory Console generates insufficient key strength
Hi, These patches add new UI to the certificate request wizard in Console that allows the key size and signing algorithms to be selected. It also improves the defaults if an older Console is used against an Admin Server with these changes. Changes were required to Admin Server for the CGI that is responsible for key and cert request generation, IDM Console Framework for the new UI (which is shared by DS and Admin Console), and to Admin Console to add new online help files.I've added a screenshot to the trac ticket showing the new panel as well. Admin Server: https://fedorahosted.org/389/attachment/ticket/362/0001-Ticket-362-Directory-Console-generates-insufficient-.patch IDM Console Framework: https://fedorahosted.org/389/attachment/ticket/362/0001-Ticket-362-Directory-Console-generates-insufficient-.2.patch Admin Console: https://fedorahosted.org/389/attachment/ticket/362/0001-Ticket-362-Directory-Console-generates-insufficient-.3.patch Screenshot: https://fedorahosted.org/389/attachment/ticket/362/console-keypanel.png Thanks, -NGK -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: Add git commit hash to developer rpm build name
From 52fb682ceb0b1f03de26b6f9d56a8ee2476d9422 Mon Sep 17 00:00:00 2001 From: Nathan Kinder nkin...@redhat.com Date: Mon, 22 Apr 2013 13:34:44 -0700 Subject: [PATCH] Add git commit hash to developer rpm build names We need to set the srcdir variable in order for the most recent git hash to be determined by VERSION.sh. This patch will result in deveoper RPM builds having the git commit hash in the release field. --- rpm/rpmverrel.sh | 4 1 file changed, 4 insertions(+) diff --git a/rpm/rpmverrel.sh b/rpm/rpmverrel.sh index 064b052..86b808e 100755 --- a/rpm/rpmverrel.sh +++ b/rpm/rpmverrel.sh @@ -1,5 +1,9 @@ #!/bin/sh +# Set srcdir so VERSION.sh is able to +# determine the last git commit hash. +srcdir=`pwd` + # Source VERSION.sh to set the version # and release environment variables. source ./VERSION.sh -- 1.8.1.4 -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please Review: Add make rpms build target
On 04/19/2013 12:04 PM, Rich Megginson wrote: On 04/19/2013 12:54 PM, Nathan Kinder wrote: Hi, Please review the attached patch that adds the ability for convenient developer RPM builds. Details are in the patch description. Note that my patch does not include any changes that will be made by running autogen.sh. I did this to make the review easier instead of cluttering things up with tons of configure changes. I will run autogen.sh before committing once the review and any necessary code adjustments are complete. Once this is checked in, I will get the nightly builds converted over to use this new build target. This should result in much less confusing package names for the nightly builds. Here is an example of a package name produced by these changes: 389-ds-base-1.3.2.a1-20130419182658.git2f02b0d.fc17.x86_64.rpm Thanks, -NGK This means that you can only do make rpms on a systemd system. That should suffice for now, and in the future, we can figure out a way to use different spec files for different platforms. Yes. This uses the spec file from Rawhide right now, but we will likely need to make the in-tree spec file conditional at some point in the future. With the current spec file, this should work on any currently supported Fedora version (F17-Rawhide). -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please Review: Add make rpms build target
On 04/19/2013 12:51 PM, Rich Megginson wrote: On 04/19/2013 01:21 PM, Nathan Kinder wrote: On 04/19/2013 12:04 PM, Rich Megginson wrote: On 04/19/2013 12:54 PM, Nathan Kinder wrote: Hi, Please review the attached patch that adds the ability for convenient developer RPM builds. Details are in the patch description. Note that my patch does not include any changes that will be made by running autogen.sh. I did this to make the review easier instead of cluttering things up with tons of configure changes. I will run autogen.sh before committing once the review and any necessary code adjustments are complete. Once this is checked in, I will get the nightly builds converted over to use this new build target. This should result in much less confusing package names for the nightly builds. Here is an example of a package name produced by these changes: 389-ds-base-1.3.2.a1-20130419182658.git2f02b0d.fc17.x86_64.rpm Thanks, -NGK This means that you can only do make rpms on a systemd system. That should suffice for now, and in the future, we can figure out a way to use different spec files for different platforms. Yes. This uses the spec file from Rawhide right now, but we will likely need to make the in-tree spec file conditional at some point in the future. With the current spec file, this should work on any currently supported Fedora version (F17-Rawhide). ok - ack Thanks! Pushed to master: Counting objects: 35, done. Delta compression using up to 8 threads. Compressing objects: 100% (13/13), done. Writing objects: 100% (20/20), 99.20 KiB, done. Total 20 (delta 15), reused 7 (delta 7) To ssh://git.fedorahosted.org/git/389/ds.git 2f02b0d..c884bd9 master - master -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: Allow RPM builds to be run without configure
HI, The previous patch for supporting developer RPM builds was useless for cases where you want to use mock for building. This new patch makes things more friendly for mock builds. It also eliminates the need to run configure before trying to build the RPMs, which was needed previously just to build the Makefile. More details are in the patch description. Thanks, -NGK From c996ae334e7a27843549318b3a970c995d58f5b6 Mon Sep 17 00:00:00 2001 From: Nathan Kinder nkin...@redhat.com Date: Fri, 19 Apr 2013 18:10:30 -0700 Subject: [PATCH] Allow rpm builds to be run without configure The previous patch that added support to build RPM packages required you to run configure before we could even create a SRPM. We had to do this since Makefile is generated by automake when configure is run. This isn't useful when you just want to create a SRPM to use for performing mock builds since the system you are creating a SRPM on might not even have the proper build dependencies availble. This patch removes the need to run configure when building RPMS. A new Makefile is added that is only used for RPM related tasks. A target to build a SRPM was also added to allow one to create a SRPM for using with mock builds. To build a SRPM or RPMS with this patch, you can just run one of the following commands with a freshly checked out source tree: make -f rpm.mk srpms make -f rpm.mk rpms The rpms, srpms, and source tarball will be creates in a dist directory in the build tree. --- Makefile.am | 41 - configure.ac | 7 --- rpm.mk | 51 +++ rpm/rpmverrel.sh | 11 +++ 4 files changed, 62 insertions(+), 48 deletions(-) create mode 100644 rpm.mk create mode 100755 rpm/rpmverrel.sh diff --git a/Makefile.am b/Makefile.am index a35f8e4..7f00b07 100644 --- a/Makefile.am +++ b/Makefile.am @@ -6,15 +6,6 @@ COLON := $(NULLSTRING):# a colon QUOTE := $(NULLSTRING)# a double quote # -# RPM Packaging -# -RPMBUILD ?= $(PWD)/rpmbuild -RPM_VERSION=@rpm_version@ -RPM_RELEASE=@rpm_release@ -RPM_NAME_VERSION=$(PACKAGE)-$(RPM_VERSION) -TARBALL=$(RPM_NAME_VERSION).tar.bz2 - -# # Compiler Flags # BUILDNUM := $(shell perl $(srcdir)/buildnum.pl) @@ -1684,35 +1675,3 @@ git-archive: fi ; \ git archive --prefix=$(distdir)/ $$gittag | bzip2 $$srcdistdir/$(distdir).tar.bz2 -local-archive: - -mkdir -p dist/$(RPM_NAME_VERSION) - rsync -a --exclude=dist --exclude=.git --exclude=rpmbuild $(srcdir)/. dist/$(RPM_NAME_VERSION) - -tarballs: local-archive - -mkdir -p dist/sources - cd dist; tar cfj sources/$(TARBALL) $(RPM_NAME_VERSION) - rm -rf dist/$(RPM_NAME_VERSION) - -rpmroot: - rm -rf $(RPMBUILD) - mkdir -p $(RPMBUILD)/BUILD - mkdir -p $(RPMBUILD)/RPMS - mkdir -p $(RPMBUILD)/SOURCES - mkdir -p $(RPMBUILD)/SPECS - mkdir -p $(RPMBUILD)/SRPMS - -rpmdistdir: - mkdir -p dist/rpms - mkdir -p dist/srpms - -rpms: rpmroot rpmdistdir tarballs - cp dist/sources/$(TARBALL) $(RPMBUILD)/SOURCES/ - cp $(srcdir)/rpm/$(PACKAGE)-* $(RPMBUILD)/SOURCES/ - sed -e s/__VERSION__/$(RPM_VERSION)/ -e s/__RELEASE__/$(RPM_RELEASE)/ \ -$(srcdir)/rpm/$(PACKAGE).spec.in $(RPMBUILD)/SPECS/$(PACKAGE).spec - rpmbuild --define _topdir $(RPMBUILD) -ba $(RPMBUILD)/SPECS/$(PACKAGE).spec - cp $(RPMBUILD)/RPMS/*/$(RPM_NAME_VERSION)-*.rpm dist/rpms/ - cp $(RPMBUILD)/RPMS/*/$(PACKAGE)-*-$(RPM_VERSION)-*.rpm dist/rpms/ - cp $(RPMBUILD)/SRPMS/$(RPM_NAME_VERSION)-*.src.rpm dist/srpms/ - rm -rf $(RPMBUILD) - diff --git a/configure.ac b/configure.ac index 7d61149..c6edbfa 100644 --- a/configure.ac +++ b/configure.ac @@ -21,10 +21,6 @@ AC_SUBST([CONSOLE_VERSION]) AM_MAINTAINER_MODE AC_CANONICAL_HOST -# Set the version and release for developer RPM builds -rpm_version=$RPM_VERSION -rpm_release=$RPM_RELEASE - # Checks for programs. AC_PROG_CXX AC_PROG_CC @@ -690,9 +686,6 @@ AC_SUBST(brand) AC_SUBST(capbrand) AC_SUBST(vendor) -AC_SUBST(rpm_version) -AC_SUBST(rpm_release) - # AC_DEFINE([USE_OLD_UNHASHED], [], [Use old unhashed code]) AC_DEFINE([LDAP_DEBUG], [1], [LDAP debug flag]) AC_DEFINE([LDAP_DONT_USE_SMARTHEAP], [1], [Don't use smartheap]) diff --git a/rpm.mk b/rpm.mk new file mode 100644 index 000..dfbadc6 --- /dev/null +++ b/rpm.mk @@ -0,0 +1,51 @@ +RPMBUILD ?= $(PWD)/rpmbuild +RPM_VERSION ?= $(shell $(PWD)/rpm/rpmverrel.sh version) +RPM_RELEASE ?= $(shell $(PWD)/rpm/rpmverrel.sh release) +PACKAGE = 389-ds-base +RPM_NAME_VERSION = $(PACKAGE)-$(RPM_VERSION) +TARBALL = $(RPM_NAME_VERSION).tar.bz2 + +clean: + rm -rf dist + rm -rf rpmbuild + +local-archive: + -mkdir -p dist/$(RPM_NAME_VERSION) + rsync -a --exclude=dist --exclude=.git --exclude=rpmbuild . dist/$(RPM_NAME_VERSION) + +tarballs: local-archive + -mkdir -p dist/sources + cd dist; tar cfj sources/$(TARBALL) $(RPM_NAME_VERSION) + rm -rf dist/$(RPM_NAME_VERSION) + +rpmroot
[389-devel] Please Review: (ticket 47734) NSS unknown protocol errors when restarting Admin Server with SSL enabled
https://fedorahosted.org/389/ticket/47334 https://fedorahosted.org/389/attachment/ticket/47334/0001-Ticket-47334-Avoid-quoting-all-settings-in-console.c.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Nightly 389 Directory Server development yum repositories
Hi, I have set up a nightly development yum repository for 389 Directory Server builds from master. There are currently builds available for Fedora 18 (x86_64 and i686). I will work on adding builds for rawhide (F19) in the near future. New builds are made nightly from the master branch in Git, which will be updated to the repo around 12:00 UTC-08:00. To set a system up to use the development repository, download the following repo file and place it in the /etc/yum.repos.d directory: http://nkinder.fedorapeople.org/389-devel/389-devel-fedora.repo It is very important to understand what the purpose of this repo is (and what it is NOT). These are test builds that are provided for convenience for use in development and testing. The builds will very likely be unstable at times. You should NOT try to run these builds for anything important. I expect these builds to be used by the 389 development team for testing as we approach the release of new official packages. I also expect that these builds will be useful for other open source projects (such as FreeIPA) who want early access to upcoming 389 Directory Server versions during their own development cycles. It is also perfectly fine to use these builds to preview upcoming features and play with them, as long don't expect everything to always be stable and working. If you do encounter issues with the development builds that seem like bugs, please let us know about them. You can bring them up on our IRC channel (#389 on FreeNode), or file a ticket for it in our Trac instance here: https://fedorahosted.org/389/ Please let me know if you encounter any problems with the repository. Thanks, -NGK -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] clarification on dn normalization
On 11/29/2012 06:49 AM, Ludwig Krispenz wrote: Hi, On 11/29/2012 03:37 PM, John Dennis wrote: On 11/29/2012 08:47 AM, Ludwig Krispenz wrote: Hi, I found an older post by KurtZeilenga: http://www.openldap.org/lists/openldap-software/200501/msg00102.html and I think RFC4517, 4.2.15. distinguishedNameMatch can be read that the comparison has to be done by avas and so dn: cn=user two,dc=example,dc=com to be compared to cn=user two,dc=example,dc=com would require to normalize the two cn parts by applying the directory string match. Yes, you make a good point and I stand corrected. The issues turns on the matching rules for specific attribute types, in this instance commonName (oid: 2.5.4.3) which does use the caseIgnoreMatch rule for Equality matching. And caseIgnoreMatch does fold whitespace. Thus you are correct the two are equivalent, but only in the context of matching (which is what you asked about). I don't know the internals of 389ds and what purpose the dn normalization plays. there are several situations where nd normalization is required, eg - in a search filter using a dn attribute like uniquemember=cn=me,o=you should find all entries with the same normalized value - a search base needs to be normalized - if an entry is added no other antry with the same dn must exist, my original example. I think you are right. The DN matching rule should be consulted during an ADD operation to check if the DN already exists. This would include space folding. Let's open up a ticket in trac for this. Thanks, -NGK Regards, Ludwig If in fact the purpose of dn normalization is to optimize the equality test between DN's then it must examine the matching rule for the *attributeType* of each AVA when comparing the attributeValue. I was thinking on a different level, DN's are often thought of as case preserving but case insensitive. However for some attributes of an AVA, an additional condition applies, white space preserving but white space insensitive after folding. Thus some DN's will compare as equal despite having unequal string representations (using case insensitive evaluation). Thank you for bringing this clarification forward. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] winsync syncs deletions of AD entries that are out of scope
On 05/04/2012 10:45 AM, Rich Megginson wrote: On 05/04/2012 11:25 AM, Rich Megginson wrote: This came up during extended testing for https://fedorahosted.org/389/ticket/355 steps: 1) make a ds user and an ad user that are in sync - verify ad changes go to ds and vice versa 2) move the ad user out of scope of the sync agreement 3) verify that sync is not working - verify ad changes don't go to ds and vice versa 4) delete the ad user - the ds user is also deleted Before the fix for ticket 355, moving the AD entry out of scope would delete the DS entry - but that was problematic - if you mis-configured your sync agreement, all of your DS users could be accidentally deleted This seems counter-intuitive - the entries are not in sync, yet the deletion is synced. This is because we do not look at the scope of the AD tombstone entry prior to deletion, and test it using is_subject_of_agreement_remote(e,prp-agmt) We could look at the AD tombstone to see if was in scope - the AD tombstone (with 2008 anyway) provides the attribute lastknownparent: (gdb) p *e-e_attrs-a_next-a_next-a_next-a_next-a_next $27 = {a_type = 0x7fffc0056bb0 lastknownparent, a_present_values = { va = 0x7fffc00563b0}, a_flags = 4, a_plugin = 0x6c85a0, a_deleted_values = {va = 0x0}, a_listtofree = 0x0, a_next = 0x7fffc0059450, a_deletioncsn = 0x0, a_mr_eq_plugin = 0x690240, a_mr_ord_plugin = 0x0, a_mr_sub_plugin = 0x0} (gdb) p *e-e_attrs-a_next-a_next-a_next-a_next-a_next-a_present_values.va[0] $28 = {bv = {bv_len = 36, bv_val = 0x7fffc0067470 CN=deletedusers,DC=testdomain,DC=com}, v_csnset = 0x0, v_flags = 0} So, in this case, if we used lastknownparent, we would see that the entry was outside of the scope of the agreement (the sync subtree is cn=testusers,dc=testdomain,dc=com). Question: In light of 355 changing the behavior - should we use lastknownparent to see if the tombstone is out of the scope of the agreement, and not delete the DS entry if so? It makes sense to use lastknownparent here. Also note: 1) When we sync deletes from DS to AD, we _do_ check to see if the entry is within the sync scope. 2) When we move a DS entry out of scope, we still delete the corresponding AD entry - should we change this behavior too? It seems like this should be consistent with how we behave when an entry is moved out of scope on the AD side (unlink but not delete). -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: coverity 12563 Read from pointer after free
On 03/07/2012 07:41 AM, Rich Megginson wrote: On 03/07/2012 07:53 AM, Nathan Kinder wrote: An additional fix is needed for this issue. Your patch fixed the dna_pre_op() function, but the same issue exists in the dna_be_txn_pre_op() function. The attached patch takes care of this. ack Thanks! Pushed to master: Counting objects: 13, done. Delta compression using up to 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 771 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git e6a9b22..6f8680a master - master On 03/06/2012 09:30 AM, Rich Megginson wrote: -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (181) Allow PAM passthru plug-in to have multiple config entries
https://fedorahosted.org/389/ticket/181 https://fedorahosted.org/389/attachment/ticket/181/0001-ticket-181-Allow-PAM-passthru-plug-in-to-have-multip.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: fix mozldap build issues
On 01/20/2012 07:02 PM, Rich Megginson wrote: -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel ack -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: reduce calls to csn_as_string and slapi_log_error
On 11/16/2011 08:48 AM, Rich Megginson wrote: -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel ack. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: csn_init_as_string should not use sscanf
On 11/16/2011 06:38 PM, Rich Megginson wrote: -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel ack. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: csn_as_string - use slapi_uN_to_hex instead of sprintf
On 11/15/2011 10:29 AM, Rich Megginson wrote: -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel ack. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: uniqueid formatting - use slapi_u8_to_hex instead of sprintf
On 11/15/2011 01:12 PM, Rich Megginson wrote: -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel ack. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: Reduce the number of DN normalization
On 10/10/2011 10:08 AM, Noriko Hosoi wrote: Reduce the number of DN normalization . Replacing SLAPI_TARGET_DN with SLAPI_TARGET_SDN (also its macros, e.g., SLAPI_SEARCH_TARGET_SDN and SLAPI_ADD_TARGET_SDN). I haven't reviewed the entire patch yet, but I am concerned about changing the APIs defined in slapi-plugin.h (such as the removal of SLAPI_TARGET_DN). This will require other plug-ins outside of the 389 source code to be ported to use this new API. This porting may be necessary in some places, but we should also try to be as backwards compatible as possible. I know that the SLAPI plug-ins used by FreeIPA use SLAPI_TARGET_DN, so they will need porting work. We will need to coordinate any API changes with them to ensure that we don't break their plug-ins. . Replacing the type of SLAPI_MODRDN_NEWSUPERIOR from (char *) to (Slapi_DN *), as well. . Replacing slapi_dn_normalization_ext call with generating Slapi_DN APIs (e.g., slapi_sdn_new_dn_...) as much as possible and stash it in pblock using SLAPI_TARGET_SDN. . When a normalized DN string is needed, get it using slapi_sdn_get_[n]dn from the stashed Slapi_DN. . Introduced a new field to Slapi_DN. udn for the original DN; dn is a normalized DN; ndn is a case- ignored normalized DN. Taking advantage of the knowledge of the stage of the DN, call the most efficient DN creating API (e.g., slapi_sdn_new_dn_... vs. slapi_sdn_new_normdn_... vs. slapi_sdn_new_ndn_...) Others . Replacing inefficient array assignment with memset (acl.c) and memcpy (idl_common.c). . Fixing invalid memory access in LASDnsBuild (lib/libaccess/lasdns.cpp). . Even if Slapi_counter is disabled, the server is allowed to start (back-ldbm/cache.c). . Fixing compiler warnings. Sorry, it's huge... -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (730387) Use POSIX RW locks instead of NSPR implementation
https://bugzilla.redhat.com/show_bug.cgi?id=730387 https://bugzilla.redhat.com/attachment.cgi?id=518567action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (729717) Windows sync logs errors when a delete is synced from AD
https://bugzilla.redhat.com/show_bug.cgi?id=729717 https://bugzilla.redhat.com/attachment.cgi?id=517697action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (728510) Run dirsync after sending updates to AD
https://bugzilla.redhat.com/show_bug.cgi?id=728510 https://bugzilla.redhat.com/attachment.cgi?id=517698action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: look for separate openldap ldif library
ack On 06/27/2011 12:03 PM, Rich Megginson wrote: This is needed to build in Fedora rawhide -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: skip rebranding current brand
ack On 06/20/2011 06:25 PM, Rich Megginson wrote: -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (710377) Segmentation fault (core dumped) while doing Import in a Replication Setup
https://bugzilla.redhat.com/show_bug.cgi?id=710377 https://bugzilla.redhat.com/attachment.cgi?id=502880action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (703530) Allow Managed Entry config to be relocated to main database
https://bugzilla.redhat.com/show_bug.cgi?id=703530 https://bugzilla.redhat.com/attachment.cgi?id=498086action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (702705) Fix Coverity NULL pointer dereferences
https://bugzilla.redhat.com/show_bug.cgi?id=702705 https://bugzilla.redhat.com/attachment.cgi?id=497407action=edit https://bugzilla.redhat.com/attachment.cgi?id=497416action=edit https://bugzilla.redhat.com/attachment.cgi?id=497429action=edit https://bugzilla.redhat.com/attachment.cgi?id=497453action=edit https://bugzilla.redhat.com/attachment.cgi?id=497459action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (700875) Cleanup ds_bring_up_server_install() in dsalib
https://bugzilla.redhat.com/show_bug.cgi?id=700875 https://bugzilla.redhat.com/attachment.cgi?id=495819action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review (697641) adminutil - Fix Coverity NULL pointer dereferences
https://bugzilla.redhat.com/show_bug.cgi?id=697641 https://bugzilla.redhat.com/attachment.cgi?id=492996action=edit https://bugzilla.redhat.com/attachment.cgi?id=493023action=edit https://bugzilla.redhat.com/attachment.cgi?id=493032action=edit https://bugzilla.redhat.com/attachment.cgi?id=493040action=edit https://bugzilla.redhat.com/attachment.cgi?id=493041action=edit https://bugzilla.redhat.com/attachment.cgi?id=493042action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (690649) Use of free'd pointer in indexing code
https://bugzilla.redhat.com/show_bug.cgi?id=690649 https://bugzilla.redhat.com/attachment.cgi?id=487435action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (689952) Incorrect bit check in replication connection code
https://bugzilla.redhat.com/show_bug.cgi?id=689952 https://bugzilla.redhat.com/attachment.cgi?id=486894action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (688341) Fix Coverity code maintainability issues
https://bugzilla.redhat.com/show_bug.cgi?id=688341 https://bugzilla.redhat.com/attachment.cgi?id=485829action=edit https://bugzilla.redhat.com/attachment.cgi?id=485851action=edit https://bugzilla.redhat.com/attachment.cgi?id=486043action=edit https://bugzilla.redhat.com/attachment.cgi?id=486053action=edit https://bugzilla.redhat.com/attachment.cgi?id=486057action=edit https://bugzilla.redhat.com/attachment.cgi?id=486059action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: (616707) Allow editing of attributes matching rules from console
https://bugzilla.redhat.com/show_bug.cgi?id=616707 https://bugzilla.redhat.com/attachment.cgi?id=483545action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (493424) remove unneeded modules for admin server apache config
https://bugzilla.redhat.com/show_bug.cgi?id=493424 https://bugzilla.redhat.com/attachment.cgi?id=480295action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (675853) dirsrv crash segfault in need_new_pw()
https://bugzilla.redhat.com/show_bug.cgi?id=675853 https://bugzilla.redhat.com/attachment.cgi?id=477699action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (670616) Allow SSF to be set for local (ldapi) connections
https://bugzilla.redhat.com/show_bug.cgi?id=670616 https://bugzilla.redhat.com/attachment.cgi?id=476468action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (527912) setup-ds.pl hangs at hostname prompt
https://bugzilla.redhat.com/show_bug.cgi?id=527912 https://bugzilla.redhat.com/attachment.cgi?id=474563action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (661102) Rename of managed entries not handled correctly
https://bugzilla.redhat.com/show_bug.cgi?id=661102 https://bugzilla.redhat.com/attachment.cgi?id=472276action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please review: [Bug 653007] db2ldif export of clear text passwords lacks storage scheme
You might want to check if you can just use slapi_is_encoded() instead of parsing for the storage scheme yourself. -NGK On 01/05/2011 06:00 PM, Noriko Hosoi wrote: https://bugzilla.redhat.com/show_bug.cgi?id=653007 https://bugzilla.redhat.com/attachment.cgi?id=471975action=diff https://bugzilla.redhat.com/attachment.cgi?id=471975action=edit Description: When passwordStorageScheme is clear, db2ldif{.pl} exports clear text passwords without the storage scheme name {CLEAR}. This patch fixes it: userPassword: {CLEAR}notsosecret Thanks, --noriko -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: (578863) Password Modify Extended Operation ignoring referrals and writing information on dedicated consumer server
https://bugzilla.redhat.com/show_bug.cgi?id=578863 https://bugzilla.redhat.com/attachment.cgi?id=405422action=diff https://bugzilla.redhat.com/attachment.cgi?id=405422action=edit -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Please Review: Managed Entries Plug-in
On 03/30/2010 03:44 PM, Rich Megginson wrote: Nathan Kinder wrote: New patch attached. Nice! Thanks for the review! mep.c:491 - value is not freed if it is not a valid filter - also would be nice to have the error message print value to show what the bogus filter is I'll address this. Do we plan on supporting binary attrs? e.g. mepstaticattr: blobattr:: base64value not sure if we care about this for the first iteration This could be nice for static attributes. I'm not really sure if it makes sense for mapped attributes or not. I'll look into how easily this could be done, but it is something we could add later as well. -NGK -NGK On 03/30/2010 01:24 PM, Nathan Kinder wrote: Please hold off on the review. I noticed one other thing that I need to address. A new patch will be sent out shortly. -NGK On 03/30/2010 01:18 PM, Nathan Kinder wrote: -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please Review: Make check for threaded httpd work with Apache 2.0
From 07346383364e6a3e37d8b2f44b305a70db26ba3c Mon Sep 17 00:00:00 2001 From: Nathan Kinder nkin...@redhat.com Date: Thu, 11 Feb 2010 16:14:54 -0800 Subject: [PATCH] Make check for threaded httpd work with Apache 2.0 The check we use for a threaded httpd doesn't properly detect a threaded Apache 2.0. This adds an additional check to the m4 file which makes this work. --- configure | 14 ++ m4/httpd.m4 | 11 --- 2 files changed, 18 insertions(+), 7 deletions(-) mode change 100644 = 100755 Makefile.in mode change 100644 = 100755 aclocal.m4 mode change 100644 = 100755 ltmain.sh diff --git a/Makefile.in b/Makefile.in old mode 100644 new mode 100755 diff --git a/aclocal.m4 b/aclocal.m4 old mode 100644 new mode 100755 diff --git a/configure b/configure index d293a35..a6d8935 100755 --- a/configure +++ b/configure @@ -23602,13 +23602,19 @@ else if test $httpd_model = yes ; then echo $as_me:$LINENO: result: good - threading model is supported 5 echo ${ECHO_T}good - threading model is supported 6 -elif test $enable_threading = yes ; then -{ { echo $as_me:$LINENO: error: threading model not supported - use --disable-threading to force use of unthreaded model 5 +else +httpd_model=`$HTTPD -V | grep APACHE_MPM_DIR | grep worker` +if test -n httpd_model ; then +echo $as_me:$LINENO: result: good - threading model is supported 5 +echo ${ECHO_T}good - threading model is supported 6 +elif test $enable_threading = yes ; then +{ { echo $as_me:$LINENO: error: threading model not supported - use --disable-threading to force use of unthreaded model 5 echo $as_me: error: threading model not supported - use --disable-threading to force use of unthreaded model 2;} { (exit 1); exit 1; }; } -else -echo $as_me:$LINENO: result: NOTICE - threading support explicitly disabled - Admin Server authorization cache will not work correctly 5 +else +echo $as_me:$LINENO: result: NOTICE - threading support explicitly disabled - Admin Server authorization cache will not work correctly 5 echo ${ECHO_T}NOTICE - threading support explicitly disabled - Admin Server authorization cache will not work correctly 6 +fi fi fi diff --git a/ltmain.sh b/ltmain.sh old mode 100644 new mode 100755 diff --git a/m4/httpd.m4 b/m4/httpd.m4 index 03a52a2..6b5b78d 100644 --- a/m4/httpd.m4 +++ b/m4/httpd.m4 @@ -93,10 +93,15 @@ else httpd_model=`$HTTPD -V | grep threaded: | awk '{print $2}'` if test $httpd_model = yes ; then AC_MSG_RESULT([good - threading model is supported]) -elif test $enable_threading = yes ; then -AC_MSG_ERROR([threading model not supported - use --disable-threading to force use of unthreaded model]) else -AC_MSG_RESULT([NOTICE - threading support explicitly disabled - Admin Server authorization cache will not work correctly]) +httpd_model=`$HTTPD -V | grep APACHE_MPM_DIR | grep worker` +if test -n httpd_model ; then +AC_MSG_RESULT([good - threading model is supported]) +elif test $enable_threading = yes ; then +AC_MSG_ERROR([threading model not supported - use --disable-threading to force use of unthreaded model]) +else +AC_MSG_RESULT([NOTICE - threading support explicitly disabled - Admin Server authorization cache will not work correctly]) +fi fi fi -- 1.6.2.5 -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel