From rmeggins at redhat.com Thu Oct 1 17:01:21 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 01 Oct 2009 11:01:21 -0600 Subject: [389-devel] 389-ds-base 1.2.3 candidate Message-ID: <4AC4E061.5080905@redhat.com> I'm testing 1.2.3 right now on f11 i386. Here is the candidate bug list: https://bugzilla.redhat.com/showdependencytree.cgi?id=519216&hide_resolved=1 The real urgency is getting the update stuff out, to fix the problems people had with upgrading from fedora ds to 389 ds in console and admin server. I'm planning to do a release into the Fedora testing repo, and create a testing repo on port389.org too -------------- 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 Oct 2 20:53:12 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 02 Oct 2009 13:53:12 -0700 Subject: [389-devel] Please Review: Add SSF bind rule to access control plug-in Message-ID: <4AC66838.3010904@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Add-ssf-bind-rule-to-access-control-plug-in.patch URL: From nhosoi at redhat.com Fri Oct 2 22:40:43 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 02 Oct 2009 15:40:43 -0700 Subject: [389-devel] Please Review: Add SSF bind rule to access control plug-in In-Reply-To: <4AC66838.3010904@redhat.com> References: <4AC66838.3010904@redhat.com> Message-ID: <4AC6816B.9070707@redhat.com> On 10/02/2009 01:53 PM, Nathan Kinder wrote: > 369e8d61a1a Mon Sep 17 00:00:00 2001 > From: Nathan Kinder From nkinder at redhat.com Fri Oct 2 22:54:38 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 02 Oct 2009 15:54:38 -0700 Subject: [389-devel] Please Review: Add SSF bind rule to access control plug-in In-Reply-To: <4AC6816B.9070707@redhat.com> References: <4AC66838.3010904@redhat.com> <4AC6816B.9070707@redhat.com> Message-ID: <4AC684AE.2040904@redhat.com> On 10/02/2009 03:40 PM, Noriko Hosoi wrote: > On 10/02/2009 01:53 PM, Nathan Kinder wrote: >> 369e8d61a1a Mon Sep 17 00:00:00 2001 >> From: Nathan Kinder Looks good. > Thanks, > --noriko Thanks for the review! Pushed to master. Counting objects: 33, done. Delta compression using 2 threads. Compressing objects: 100% (17/17), done. Writing objects: 100% (17/17), 3.37 KiB, done. Total 17 (delta 15), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git ab6e5a7..5593a5f master -> master > > ------------------------------------------------------------------------ > > -- > 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 Oct 5 20:37:22 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 05 Oct 2009 13:37:22 -0700 Subject: [389-devel] Please Review: Allow anonymous bind resource limits to be set Message-ID: <4ACA5902.40404@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Allow-anonymous-bind-resource-limits-to-be-set.patch URL: From nkinder at redhat.com Mon Oct 5 22:36:35 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 05 Oct 2009 15:36:35 -0700 Subject: [389-devel] Please Review: Allow anonymous bind resource limits to be set In-Reply-To: <4ACA5902.40404@redhat.com> References: <4ACA5902.40404@redhat.com> Message-ID: <4ACA74F3.5080508@redhat.com> Here's a revised patch. Rich caught a small memory leak caused by my moving around some code just before I sent it out for review. On 10/05/2009 01:37 PM, Nathan Kinder wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Allow-anonymous-bind-resource-limits-to-be-set.patch URL: From nhosoi at redhat.com Mon Oct 5 22:41:23 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 05 Oct 2009 15:41:23 -0700 Subject: [389-devel] Please Review: Allow anonymous bind resource limits to be set In-Reply-To: <4ACA74F3.5080508@redhat.com> References: <4ACA5902.40404@redhat.com> <4ACA74F3.5080508@redhat.com> Message-ID: <4ACA7613.10507@redhat.com> On 10/05/2009 03:36 PM, Nathan Kinder wrote: > Here's a revised patch. Rich caught a small memory leak caused by my > moving around some code just before I sent it out for review. > > On 10/05/2009 01:37 PM, Nathan Kinder 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 > ack --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 Mon Oct 5 23:01:30 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 05 Oct 2009 16:01:30 -0700 Subject: [389-devel] Please Review: Allow anonymous bind resource limits to be set In-Reply-To: <4ACA7613.10507@redhat.com> References: <4ACA5902.40404@redhat.com> <4ACA74F3.5080508@redhat.com> <4ACA7613.10507@redhat.com> Message-ID: <4ACA7ACA.7000707@redhat.com> On 10/05/2009 03:41 PM, Noriko Hosoi wrote: > On 10/05/2009 03:36 PM, Nathan Kinder wrote: >> Here's a revised patch. Rich caught a small memory leak caused by my >> moving around some code just before I sent it out for review. >> >> On 10/05/2009 01:37 PM, Nathan Kinder 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 >> > ack > --noriko Thanks for the reviews! Pushed to master. Counting objects: 17, done. Delta compression using 2 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (9/9), 1.52 KiB, done. Total 9 (delta 7), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 5593a5f..6eb6e4b master -> master > ------------------------------------------------------------------------ > > -- > 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 Oct 6 02:25:55 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 05 Oct 2009 20:25:55 -0600 Subject: [389-devel] Please review: more updates - add missing rundir - remove ldapiautodnsuffix Message-ID: <4ACAAAB3.1000103@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-more-updates-add-missing-rundir-remove-ldapiauto.patch Type: text/x-patch Size: 9344 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 Tue Oct 6 02:37:28 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 05 Oct 2009 20:37:28 -0600 Subject: [389-devel] Please review: auto upgrade during rpm posttrans Message-ID: <4ACAAD68.3050003@redhat.com> It is a problem that upgrade is not run automatically during rpm installation. It causes problems for other packages that depend on 389. This fix allows rpm to run the upgrade script. Some notes: * had to write scriptlets in lua to allow data to be passed among different phases - %posttrans does not know if it is being run as a fresh install or an upgrade, so we have to get that information from %post to pass to %posttrans * upgrade must be run in posttrans - in %post, the old package that is being upgraded will still be around - this includes the old schema in the schema dir - the update script assumes the contents of the schema dir are correct and current - so we have to wait until %posttrans when the schema dir will contain only the new schema * the upgrade script can only run non-interactively if the servers are all shutdown first - so we have to shutdown the servers, run the upgrade, then start the servers back up - however, if the user did not want certain servers to be running, we first get a list of the running servers, and only start those back up after the upgrade -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diffs 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 Oct 6 15:07:12 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 06 Oct 2009 08:07:12 -0700 Subject: [389-devel] Please review: more updates - add missing rundir - remove ldapiautodnsuffix In-Reply-To: <4ACAAAB3.1000103@redhat.com> References: <4ACAAAB3.1000103@redhat.com> Message-ID: <4ACB5D20.9010709@redhat.com> On 10/05/2009 07:25 PM, Rich Megginson wrote: > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > ack. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Tue Oct 6 15:25:58 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 06 Oct 2009 08:25:58 -0700 Subject: [389-devel] Please review: auto upgrade during rpm posttrans In-Reply-To: <4ACAAD68.3050003@redhat.com> References: <4ACAAD68.3050003@redhat.com> Message-ID: <4ACB6186.8070800@redhat.com> On 10/05/2009 07:37 PM, Rich Megginson wrote: > It is a problem that upgrade is not run automatically during rpm > installation. It causes problems for other packages that depend on > 389. This fix allows rpm to run the upgrade script. Some notes: > * had to write scriptlets in lua to allow data to be passed among > different phases - %posttrans does not know if it is being run as a > fresh install or an upgrade, so we have to get that information from > %post to pass to %posttrans > * upgrade must be run in posttrans - in %post, the old package that is > being upgraded will still be around - this includes the old schema in > the schema dir - the update script assumes the contents of the schema > dir are correct and current - so we have to wait until %posttrans when > the schema dir will contain only the new schema > * the upgrade script can only run non-interactively if the servers are > all shutdown first - so we have to shutdown the servers, run the > upgrade, then start the servers back up - however, if the user did not > want certain servers to be running, we first get a list of the running > servers, and only start those back up after the upgrade > > ------------------------------------------------------------------------ > > I believe you need to add something like the following since you added the new dirsrv-snmp init script to the package: %post os.execute('/sbin/chkconfig --add %{pkgname}') %postun /sbin/service %{pkgname}-snmp stop >/dev/null 2>&1 || : /sbin/chkconfig --del %{pkgname}-snmp Other than that, it looks good. > -- > 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 Tue Oct 6 15:28:13 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 06 Oct 2009 08:28:13 -0700 Subject: [389-devel] Please review: auto upgrade during rpm posttrans In-Reply-To: <4ACB6186.8070800@redhat.com> References: <4ACAAD68.3050003@redhat.com> <4ACB6186.8070800@redhat.com> Message-ID: <4ACB620D.2020803@redhat.com> On 10/06/2009 08:25 AM, Nathan Kinder wrote: > On 10/05/2009 07:37 PM, Rich Megginson wrote: >> It is a problem that upgrade is not run automatically during rpm >> installation. It causes problems for other packages that depend on >> 389. This fix allows rpm to run the upgrade script. Some notes: >> * had to write scriptlets in lua to allow data to be passed among >> different phases - %posttrans does not know if it is being run as a >> fresh install or an upgrade, so we have to get that information from >> %post to pass to %posttrans >> * upgrade must be run in posttrans - in %post, the old package that >> is being upgraded will still be around - this includes the old schema >> in the schema dir - the update script assumes the contents of the >> schema dir are correct and current - so we have to wait until >> %posttrans when the schema dir will contain only the new schema >> * the upgrade script can only run non-interactively if the servers >> are all shutdown first - so we have to shutdown the servers, run the >> upgrade, then start the servers back up - however, if the user did >> not want certain servers to be running, we first get a list of the >> running servers, and only start those back up after the upgrade >> >> ------------------------------------------------------------------------ >> >> > I believe you need to add something like the following since you added > the new dirsrv-snmp init script to the package: > > %post > os.execute('/sbin/chkconfig --add %{pkgname}') Sorry, I meant the following for the above line: os.execute('/sbin/chkconfig --add %{pkgname}-snmp') > > %postun > /sbin/service %{pkgname}-snmp stop >/dev/null 2>&1 || : > /sbin/chkconfig --del %{pkgname}-snmp > > Other than that, it looks good. >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Oct 7 15:07:05 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 07 Oct 2009 09:07:05 -0600 Subject: [389-devel] Please review: more updates - add missing rundir - remove ldapiautodnsuffix In-Reply-To: <4ACB5D20.9010709@redhat.com> References: <4ACAAAB3.1000103@redhat.com> <4ACB5D20.9010709@redhat.com> Message-ID: <4ACCAE99.8090607@redhat.com> Nathan Kinder wrote: > On 10/05/2009 07:25 PM, Rich Megginson wrote: >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > ack. Thanks - pushed to master > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Wed Oct 7 15:44:55 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 07 Oct 2009 09:44:55 -0600 Subject: [389-devel] Please review: auto upgrade during rpm posttrans In-Reply-To: <4ACB620D.2020803@redhat.com> References: <4ACAAD68.3050003@redhat.com> <4ACB6186.8070800@redhat.com> <4ACB620D.2020803@redhat.com> Message-ID: <4ACCB777.3090207@redhat.com> Nathan Kinder wrote: > On 10/06/2009 08:25 AM, Nathan Kinder wrote: >> On 10/05/2009 07:37 PM, Rich Megginson wrote: >>> It is a problem that upgrade is not run automatically during rpm >>> installation. It causes problems for other packages that depend on >>> 389. This fix allows rpm to run the upgrade script. Some notes: >>> * had to write scriptlets in lua to allow data to be passed among >>> different phases - %posttrans does not know if it is being run as a >>> fresh install or an upgrade, so we have to get that information from >>> %post to pass to %posttrans >>> * upgrade must be run in posttrans - in %post, the old package that >>> is being upgraded will still be around - this includes the old >>> schema in the schema dir - the update script assumes the contents of >>> the schema dir are correct and current - so we have to wait until >>> %posttrans when the schema dir will contain only the new schema >>> * the upgrade script can only run non-interactively if the servers >>> are all shutdown first - so we have to shutdown the servers, run the >>> upgrade, then start the servers back up - however, if the user did >>> not want certain servers to be running, we first get a list of the >>> running servers, and only start those back up after the upgrade >>> >>> ------------------------------------------------------------------------ >>> >>> >> I believe you need to add something like the following since you >> added the new dirsrv-snmp init script to the package: >> >> %post >> os.execute('/sbin/chkconfig --add %{pkgname}') > Sorry, I meant the following for the above line: > os.execute('/sbin/chkconfig --add %{pkgname}-snmp') >> >> %postun >> /sbin/service %{pkgname}-snmp stop >/dev/null 2>&1 || : >> /sbin/chkconfig --del %{pkgname}-snmp >> >> Other than that, it looks good. Thanks. Checked into CVS >>> -- >>> 389-devel mailing list >>> 389-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Wed Oct 7 18:03:27 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 07 Oct 2009 11:03:27 -0700 Subject: [389-devel] Please Review: (Admin Server) Get rundir from sysconfig script Message-ID: <4ACCD7EF.2000203@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Get-rundir-from-sysconfig-script.patch URL: From nhosoi at redhat.com Wed Oct 7 20:22:06 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 07 Oct 2009 13:22:06 -0700 Subject: [389-devel] Please Review: (Admin Server) Get rundir from sysconfig script In-Reply-To: <4ACCD7EF.2000203@redhat.com> References: <4ACCD7EF.2000203@redhat.com> Message-ID: <4ACCF86E.2090003@redhat.com> On 10/07/2009 11:03 AM, 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 -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Wed Oct 7 22:47:35 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 07 Oct 2009 15:47:35 -0700 Subject: [389-devel] Please Review: (Admin Server) Get rundir from sysconfig script In-Reply-To: <4ACCF86E.2090003@redhat.com> References: <4ACCD7EF.2000203@redhat.com> <4ACCF86E.2090003@redhat.com> Message-ID: <4ACD1A87.2090503@redhat.com> On 10/07/2009 01:22 PM, Noriko Hosoi wrote: > On 10/07/2009 11:03 AM, Nathan Kinder wrote: >> >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > Looks good. Thanks. Pushed to master. Counting objects: 13, done. Delta compression using 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (7/7), 1.78 KiB, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/admin.git eb25bdf..e696425 master -> master > --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 rmeggins at redhat.com Thu Oct 8 18:37:39 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 08 Oct 2009 12:37:39 -0600 Subject: [389-devel] various admin server stuff Message-ID: <4ACE3173.3010105@redhat.com> I'd like to move mod_admserv and mod_restartd into the admin.git repo as sub-directories. I couldn't figure out a way to migrate the CVS history data into a git subdirectory, so I was thinking about just copying the files in there with no history. Is this ok? We can always refer back to the old CVS repo if we need to see history. It turns out we can't get rid of mod_restartd and use mod_suexec. mod_suexec explicitly forbids running CGIs as root, so we can't use that to start the servers. I don't really like the fact that we have to support this module for the sole purpose of being able to remotely start, restart, and create instances of servers that run on low ports. For one, mod_restartd is and always will be a security nightmare waiting to happen - it is just a bad, bad idea to execute CGIs as root (or run the admin server as root). For another, usually init or something like daemontools does a much better job of making sure remote servers are running (e.g. restarting after a crash). You always have to run setup-ds-admin.pl when installing on a remote system, and that creates the directory server instance, so I'm not really sure how useful it is to be able to remotely create instances. I'd like to propose that we make this feature optional (that is, can build admin server without it) and possibly get rid of it altogether. I would also like to relax the requirement that we have to use the threaded model Apache. The only reason we require this is because mod_admserv caches the auth credentials and ACIs in memory, in case you need to perform a task while the config DS is down (e.g. like start or restart). There are a few changes required to mod_admserv to relax this restriction. -------------- 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 Oct 8 20:16:14 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 08 Oct 2009 13:16:14 -0700 Subject: [389-devel] various admin server stuff In-Reply-To: <4ACE3173.3010105@redhat.com> References: <4ACE3173.3010105@redhat.com> Message-ID: <4ACE488E.5060505@redhat.com> On 10/08/2009 11:37 AM, Rich Megginson wrote: > I'd like to move mod_admserv and mod_restartd into the admin.git repo > as sub-directories. I couldn't figure out a way to migrate the CVS > history data into a git subdirectory, so I was thinking about just > copying the files in there with no history. Is this ok? We can > always refer back to the old CVS repo if we need to see history. I think this is fine. As you say, we can always look at the old CVS repo if needed. > > It turns out we can't get rid of mod_restartd and use mod_suexec. > mod_suexec explicitly forbids running CGIs as root, so we can't use > that to start the servers. I don't really like the fact that we have > to support this module for the sole purpose of being able to remotely > start, restart, and create instances of servers that run on low > ports. For one, mod_restartd is and always will be a security > nightmare waiting to happen - it is just a bad, bad idea to execute > CGIs as root (or run the admin server as root). Agreed. We can mitigate the risk some by constraining things with SELinux policy. > For another, usually init or something like daemontools does a much > better job of making sure remote servers are running (e.g. restarting > after a crash). You always have to run setup-ds-admin.pl when > installing on a remote system, and that creates the directory server > instance, so I'm not really sure how useful it is to be able to > remotely create instances. I'd like to propose that we make this > feature optional (that is, can build admin server without it) and > possibly get rid of it altogether. It doesn't seem too common for people to run multiple instances on the same system out in the wild. Even for those who do, I would imagine that instance creation is not a common occurrence, and this would really only affect Console users. This would mean that changes are needed to Console to get rid of the "Create Instance" task though. > > I would also like to relax the requirement that we have to use the > threaded model Apache. The only reason we require this is because > mod_admserv caches the auth credentials and ACIs in memory, in case > you need to perform a task while the config DS is down (e.g. like > start or restart). There are a few changes required to mod_admserv to > relax this restriction. If the threaded model is not used, does that mean you can't perform tasks when the config DS is down, even with the changes you have in mind? > > ------------------------------------------------------------------------ > > -- > 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 Thu Oct 8 20:29:52 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 08 Oct 2009 14:29:52 -0600 Subject: [389-devel] various admin server stuff In-Reply-To: <4ACE488E.5060505@redhat.com> References: <4ACE3173.3010105@redhat.com> <4ACE488E.5060505@redhat.com> Message-ID: <4ACE4BC0.3090408@redhat.com> Nathan Kinder wrote: > On 10/08/2009 11:37 AM, Rich Megginson wrote: >> I'd like to move mod_admserv and mod_restartd into the admin.git repo >> as sub-directories. I couldn't figure out a way to migrate the CVS >> history data into a git subdirectory, so I was thinking about just >> copying the files in there with no history. Is this ok? We can >> always refer back to the old CVS repo if we need to see history. > I think this is fine. As you say, we can always look at the old CVS > repo if needed. >> >> It turns out we can't get rid of mod_restartd and use mod_suexec. >> mod_suexec explicitly forbids running CGIs as root, so we can't use >> that to start the servers. I don't really like the fact that we have >> to support this module for the sole purpose of being able to remotely >> start, restart, and create instances of servers that run on low >> ports. For one, mod_restartd is and always will be a security >> nightmare waiting to happen - it is just a bad, bad idea to execute >> CGIs as root (or run the admin server as root). > Agreed. We can mitigate the risk some by constraining things with > SELinux policy. >> For another, usually init or something like daemontools does a much >> better job of making sure remote servers are running (e.g. restarting >> after a crash). You always have to run setup-ds-admin.pl when >> installing on a remote system, and that creates the directory server >> instance, so I'm not really sure how useful it is to be able to >> remotely create instances. I'd like to propose that we make this >> feature optional (that is, can build admin server without it) and >> possibly get rid of it altogether. > It doesn't seem too common for people to run multiple instances on the > same system out in the wild. Even for those who do, I would imagine > that instance creation is not a common occurrence, and this would > really only affect Console users. This would mean that changes are > needed to Console to get rid of the "Create Instance" task though. >> >> I would also like to relax the requirement that we have to use the >> threaded model Apache. The only reason we require this is because >> mod_admserv caches the auth credentials and ACIs in memory, in case >> you need to perform a task while the config DS is down (e.g. like >> start or restart). There are a few changes required to mod_admserv >> to relax this restriction. > If the threaded model is not used, does that mean you can't perform > tasks when the config DS is down, even with the changes you have in mind? You would not be able to perform CGI based tasks, such as - manage certs, view logs, stop/start/restart, create instance - and you would be able to do very few, if any, admin server web or console tasks. The other way to do it would be to run apache in prefork mode, but just have one server process (set the number of servers to fork to 1). Then you could use the prefork apache, with no threading, but still have the cache available. If you have more than one process, each one will have a separate cache, which may or may not contain the current auth and ACI cache, so it will just be luck to have the correct apache process with the correct cache serve your request. Of course we could move to a model where the cache is stored in shared memory, or disk file with flock/lockf access, or some other IPC model, but that seems like a lot of work for little benefit. The whole point of this is to mitigate the effect of a downed config DS, and some other method should be used to ensure that the config DS is always available (e.g. init/daemontools - see above). >> >> ------------------------------------------------------------------------ >> >> -- >> 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 nkinder at redhat.com Thu Oct 8 20:47:06 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 08 Oct 2009 13:47:06 -0700 Subject: [389-devel] various admin server stuff In-Reply-To: <4ACE4BC0.3090408@redhat.com> References: <4ACE3173.3010105@redhat.com> <4ACE488E.5060505@redhat.com> <4ACE4BC0.3090408@redhat.com> Message-ID: <4ACE4FCA.2080506@redhat.com> On 10/08/2009 01:29 PM, Rich Megginson wrote: > Nathan Kinder wrote: >> On 10/08/2009 11:37 AM, Rich Megginson wrote: >>> I'd like to move mod_admserv and mod_restartd into the admin.git >>> repo as sub-directories. I couldn't figure out a way to migrate the >>> CVS history data into a git subdirectory, so I was thinking about >>> just copying the files in there with no history. Is this ok? We >>> can always refer back to the old CVS repo if we need to see history. >> I think this is fine. As you say, we can always look at the old CVS >> repo if needed. >>> >>> It turns out we can't get rid of mod_restartd and use mod_suexec. >>> mod_suexec explicitly forbids running CGIs as root, so we can't use >>> that to start the servers. I don't really like the fact that we >>> have to support this module for the sole purpose of being able to >>> remotely start, restart, and create instances of servers that run on >>> low ports. For one, mod_restartd is and always will be a security >>> nightmare waiting to happen - it is just a bad, bad idea to execute >>> CGIs as root (or run the admin server as root). >> Agreed. We can mitigate the risk some by constraining things with >> SELinux policy. >>> For another, usually init or something like daemontools does a >>> much better job of making sure remote servers are running (e.g. >>> restarting after a crash). You always have to run setup-ds-admin.pl >>> when installing on a remote system, and that creates the directory >>> server instance, so I'm not really sure how useful it is to be able >>> to remotely create instances. I'd like to propose that we make this >>> feature optional (that is, can build admin server without it) and >>> possibly get rid of it altogether. >> It doesn't seem too common for people to run multiple instances on >> the same system out in the wild. Even for those who do, I would >> imagine that instance creation is not a common occurrence, and this >> would really only affect Console users. This would mean that changes >> are needed to Console to get rid of the "Create Instance" task though. >>> >>> I would also like to relax the requirement that we have to use the >>> threaded model Apache. The only reason we require this is because >>> mod_admserv caches the auth credentials and ACIs in memory, in case >>> you need to perform a task while the config DS is down (e.g. like >>> start or restart). There are a few changes required to mod_admserv >>> to relax this restriction. >> If the threaded model is not used, does that mean you can't perform >> tasks when the config DS is down, even with the changes you have in >> mind? > You would not be able to perform CGI based tasks, such as - manage > certs, view logs, stop/start/restart, create instance - and you would > be able to do very few, if any, admin server web or console tasks. > > The other way to do it would be to run apache in prefork mode, but > just have one server process (set the number of servers to fork to > 1). Then you could use the prefork apache, with no threading, but > still have the cache available. This sounds best to me. Is there any real need for multiple processes here? It's not like the admin server should be dealing with tons of requests from different clients. The use case is really one administrator using console (or Admin Express) to manage their Directory Severs. Is there some other benefit we lose by moving to a single process with no threading that I'm not thinking of? > If you have more than one process, each one will have a separate > cache, which may or may not contain the current auth and ACI cache, so > it will just be luck to have the correct apache process with the > correct cache serve your request. Of course we could move to a model > where the cache is stored in shared memory, or disk file with > flock/lockf access, or some other IPC model, but that seems like a lot > of work for little benefit. Yeah, too much work for no real benefit IMHO. > The whole point of this is to mitigate the effect of a downed config > DS, and some other method should be used to ensure that the config DS > is always available (e.g. init/daemontools - see above). One point to bring up here is that it may be preferable to not use your config DS for anything other than being the config DS. This would mean most people would want to create a second instance on the same system, which they would only be able to do with setup-ds-admin.pl if we pull that capability out of the Console/CGI. I don't think that is a big deal though. >>> >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> 389-devel mailing list >>> 389-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Oct 8 20:58:16 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 08 Oct 2009 14:58:16 -0600 Subject: [389-devel] various admin server stuff In-Reply-To: <4ACE4FCA.2080506@redhat.com> References: <4ACE3173.3010105@redhat.com> <4ACE488E.5060505@redhat.com> <4ACE4BC0.3090408@redhat.com> <4ACE4FCA.2080506@redhat.com> Message-ID: <4ACE5268.6070806@redhat.com> Nathan Kinder wrote: > On 10/08/2009 01:29 PM, Rich Megginson wrote: >> Nathan Kinder wrote: >>> On 10/08/2009 11:37 AM, Rich Megginson wrote: >>>> I'd like to move mod_admserv and mod_restartd into the admin.git >>>> repo as sub-directories. I couldn't figure out a way to migrate >>>> the CVS history data into a git subdirectory, so I was thinking >>>> about just copying the files in there with no history. Is this >>>> ok? We can always refer back to the old CVS repo if we need to see >>>> history. >>> I think this is fine. As you say, we can always look at the old CVS >>> repo if needed. >>>> >>>> It turns out we can't get rid of mod_restartd and use mod_suexec. >>>> mod_suexec explicitly forbids running CGIs as root, so we can't use >>>> that to start the servers. I don't really like the fact that we >>>> have to support this module for the sole purpose of being able to >>>> remotely start, restart, and create instances of servers that run >>>> on low ports. For one, mod_restartd is and always will be a >>>> security nightmare waiting to happen - it is just a bad, bad idea >>>> to execute CGIs as root (or run the admin server as root). >>> Agreed. We can mitigate the risk some by constraining things with >>> SELinux policy. >>>> For another, usually init or something like daemontools does a >>>> much better job of making sure remote servers are running (e.g. >>>> restarting after a crash). You always have to run >>>> setup-ds-admin.pl when installing on a remote system, and that >>>> creates the directory server instance, so I'm not really sure how >>>> useful it is to be able to remotely create instances. I'd like to >>>> propose that we make this feature optional (that is, can build >>>> admin server without it) and possibly get rid of it altogether. >>> It doesn't seem too common for people to run multiple instances on >>> the same system out in the wild. Even for those who do, I would >>> imagine that instance creation is not a common occurrence, and this >>> would really only affect Console users. This would mean that >>> changes are needed to Console to get rid of the "Create Instance" >>> task though. >>>> >>>> I would also like to relax the requirement that we have to use the >>>> threaded model Apache. The only reason we require this is because >>>> mod_admserv caches the auth credentials and ACIs in memory, in case >>>> you need to perform a task while the config DS is down (e.g. like >>>> start or restart). There are a few changes required to mod_admserv >>>> to relax this restriction. >>> If the threaded model is not used, does that mean you can't perform >>> tasks when the config DS is down, even with the changes you have in >>> mind? >> You would not be able to perform CGI based tasks, such as - manage >> certs, view logs, stop/start/restart, create instance - and you would >> be able to do very few, if any, admin server web or console tasks. >> >> The other way to do it would be to run apache in prefork mode, but >> just have one server process (set the number of servers to fork to >> 1). Then you could use the prefork apache, with no threading, but >> still have the cache available. > This sounds best to me. Is there any real need for multiple processes > here? It's not like the admin server should be dealing with tons of > requests from different clients. The use case is really one > administrator using console (or Admin Express) to manage their > Directory Severs. Is there some other benefit we lose by moving to a > single process with no threading that I'm not thinking of? Gateway/phonebook/org chart - the default is to run these through the primary admin server - those apps are stateless/cacheless and would work just fine under plain old apache, regardless of the worker model. >> If you have more than one process, each one will have a separate >> cache, which may or may not contain the current auth and ACI cache, >> so it will just be luck to have the correct apache process with the >> correct cache serve your request. Of course we could move to a model >> where the cache is stored in shared memory, or disk file with >> flock/lockf access, or some other IPC model, but that seems like a >> lot of work for little benefit. > Yeah, too much work for no real benefit IMHO. >> The whole point of this is to mitigate the effect of a downed >> config DS, and some other method should be used to ensure that the >> config DS is always available (e.g. init/daemontools - see above). > One point to bring up here is that it may be preferable to not use > your config DS for anything other than being the config DS. This > would mean most people would want to create a second instance on the > same system, which they would only be able to do with > setup-ds-admin.pl if we pull that capability out of the Console/CGI. > I don't think that is a big deal though. You can already use setup-ds-admin.pl to create another instance. >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> -- >>>> 389-devel mailing list >>>> 389-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> 389-devel mailing list >>> 389-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 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 Thu Oct 8 21:06:29 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 08 Oct 2009 14:06:29 -0700 Subject: [389-devel] various admin server stuff In-Reply-To: <4ACE5268.6070806@redhat.com> References: <4ACE3173.3010105@redhat.com> <4ACE488E.5060505@redhat.com> <4ACE4BC0.3090408@redhat.com> <4ACE4FCA.2080506@redhat.com> <4ACE5268.6070806@redhat.com> Message-ID: <4ACE5455.60601@redhat.com> On 10/08/2009 01:58 PM, Rich Megginson wrote: > Nathan Kinder wrote: >> On 10/08/2009 01:29 PM, Rich Megginson wrote: >>> Nathan Kinder wrote: >>>> On 10/08/2009 11:37 AM, Rich Megginson wrote: >>>>> I'd like to move mod_admserv and mod_restartd into the admin.git >>>>> repo as sub-directories. I couldn't figure out a way to migrate >>>>> the CVS history data into a git subdirectory, so I was thinking >>>>> about just copying the files in there with no history. Is this >>>>> ok? We can always refer back to the old CVS repo if we need to >>>>> see history. >>>> I think this is fine. As you say, we can always look at the old >>>> CVS repo if needed. >>>>> >>>>> It turns out we can't get rid of mod_restartd and use mod_suexec. >>>>> mod_suexec explicitly forbids running CGIs as root, so we can't >>>>> use that to start the servers. I don't really like the fact that >>>>> we have to support this module for the sole purpose of being able >>>>> to remotely start, restart, and create instances of servers that >>>>> run on low ports. For one, mod_restartd is and always will be a >>>>> security nightmare waiting to happen - it is just a bad, bad idea >>>>> to execute CGIs as root (or run the admin server as root). >>>> Agreed. We can mitigate the risk some by constraining things with >>>> SELinux policy. >>>>> For another, usually init or something like daemontools does a >>>>> much better job of making sure remote servers are running (e.g. >>>>> restarting after a crash). You always have to run >>>>> setup-ds-admin.pl when installing on a remote system, and that >>>>> creates the directory server instance, so I'm not really sure how >>>>> useful it is to be able to remotely create instances. I'd like to >>>>> propose that we make this feature optional (that is, can build >>>>> admin server without it) and possibly get rid of it altogether. >>>> It doesn't seem too common for people to run multiple instances on >>>> the same system out in the wild. Even for those who do, I would >>>> imagine that instance creation is not a common occurrence, and this >>>> would really only affect Console users. This would mean that >>>> changes are needed to Console to get rid of the "Create Instance" >>>> task though. >>>>> >>>>> I would also like to relax the requirement that we have to use the >>>>> threaded model Apache. The only reason we require this is because >>>>> mod_admserv caches the auth credentials and ACIs in memory, in >>>>> case you need to perform a task while the config DS is down (e.g. >>>>> like start or restart). There are a few changes required to >>>>> mod_admserv to relax this restriction. >>>> If the threaded model is not used, does that mean you can't perform >>>> tasks when the config DS is down, even with the changes you have in >>>> mind? >>> You would not be able to perform CGI based tasks, such as - manage >>> certs, view logs, stop/start/restart, create instance - and you >>> would be able to do very few, if any, admin server web or console >>> tasks. >>> >>> The other way to do it would be to run apache in prefork mode, but >>> just have one server process (set the number of servers to fork to >>> 1). Then you could use the prefork apache, with no threading, but >>> still have the cache available. >> This sounds best to me. Is there any real need for multiple >> processes here? It's not like the admin server should be dealing >> with tons of requests from different clients. The use case is really >> one administrator using console (or Admin Express) to manage their >> Directory Severs. Is there some other benefit we lose by moving to a >> single process with no threading that I'm not thinking of? > Gateway/phonebook/org chart - the default is to run these through the > primary admin server - those apps are stateless/cacheless and would > work just fine under plain old apache, regardless of the worker model. So we could just recommend that those apps not be run under Admin Server in production environments for performance reasons, but instead run them under plain Apache webserver and configure as the admin sees fit. >>> If you have more than one process, each one will have a separate >>> cache, which may or may not contain the current auth and ACI cache, >>> so it will just be luck to have the correct apache process with the >>> correct cache serve your request. Of course we could move to a >>> model where the cache is stored in shared memory, or disk file with >>> flock/lockf access, or some other IPC model, but that seems like a >>> lot of work for little benefit. >> Yeah, too much work for no real benefit IMHO. >>> The whole point of this is to mitigate the effect of a downed >>> config DS, and some other method should be used to ensure that the >>> config DS is always available (e.g. init/daemontools - see above). >> One point to bring up here is that it may be preferable to not use >> your config DS for anything other than being the config DS. This >> would mean most people would want to create a second instance on the >> same system, which they would only be able to do with >> setup-ds-admin.pl if we pull that capability out of the Console/CGI. >> I don't think that is a big deal though. > You can already use setup-ds-admin.pl to create another instance. >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> -- >>>>> 389-devel mailing list >>>>> 389-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> -- >>>> 389-devel mailing list >>>> 389-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> 389-devel mailing list >>> 389-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> >> ------------------------------------------------------------------------ >> >> -- >> 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 Thu Oct 8 22:11:23 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 08 Oct 2009 16:11:23 -0600 Subject: [389-devel] Please review again: move mod_admserv and mod_restartd into adminserver Message-ID: <4ACE638B.5040409@redhat.com> This patch is much smaller - ignore previous post -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Move-mod_admserv-and-mod_restartd-into-adminserver.patch Type: text/x-patch Size: 8770 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 Thu Oct 8 22:28:57 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 08 Oct 2009 15:28:57 -0700 Subject: [389-devel] Please review again: move mod_admserv and mod_restartd into adminserver In-Reply-To: <4ACE638B.5040409@redhat.com> References: <4ACE638B.5040409@redhat.com> Message-ID: <4ACE67A9.7050903@redhat.com> On 10/08/2009 03:11 PM, Rich Megginson wrote: > This patch is much smaller - ignore previous post ack. > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Oct 8 22:32:54 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 08 Oct 2009 16:32:54 -0600 Subject: [389-devel] Please review again: move mod_admserv and mod_restartd into adminserver In-Reply-To: <4ACE67A9.7050903@redhat.com> References: <4ACE638B.5040409@redhat.com> <4ACE67A9.7050903@redhat.com> Message-ID: <4ACE6896.9040004@redhat.com> Nathan Kinder wrote: > On 10/08/2009 03:11 PM, Rich Megginson wrote: >> This patch is much smaller - ignore previous post > ack. Thanks - pushed to master I also bumped the version to 1.1.10 >> >> ------------------------------------------------------------------------ >> >> -- >> 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 Fri Oct 9 00:58:09 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 08 Oct 2009 18:58:09 -0600 Subject: [389-devel] Please review: allow use of Apache without threading support Message-ID: <4ACE8AA1.9080408@redhat.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-use-of-unthreaded-Apache.patch Type: text/x-patch Size: 5010 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 Fri Oct 9 14:23:38 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 09 Oct 2009 07:23:38 -0700 Subject: [389-devel] Please review: allow use of Apache without threading support In-Reply-To: <4ACE8AA1.9080408@redhat.com> References: <4ACE8AA1.9080408@redhat.com> Message-ID: <4ACF476A.1080104@redhat.com> On 10/08/2009 05:58 PM, Rich Megginson wrote: > > ack. > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Oct 9 16:14:04 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 09 Oct 2009 10:14:04 -0600 Subject: [389-devel] Please review: allow use of Apache without threading support In-Reply-To: <4ACF476A.1080104@redhat.com> References: <4ACE8AA1.9080408@redhat.com> <4ACF476A.1080104@redhat.com> Message-ID: <4ACF614C.7040704@redhat.com> Nathan Kinder wrote: > On 10/08/2009 05:58 PM, Rich Megginson wrote: >> >> > ack. Thanks - pushed to master configure | 94 +++++++++++++++++++++++++++++------------ lib/libdsa/dsalib_location.c | 1 + m4/httpd.m4 | 25 +++++++++++ mod_admserv/mod_admserv.c | 11 +++-- 4 files changed, 98 insertions(+), 33 deletions(-) Counting objects: 19, done. Compressing objects: 100% (10/10), done. Writing objects: 100% (10/10), 2.87 KiB, done. Total 10 (delta 8), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/admin.git 14fd2ef..928e651 master -> master >> ------------------------------------------------------------------------ >> >> -- >> 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 Fri Oct 9 16:24:43 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 09 Oct 2009 10:24:43 -0600 Subject: [389-devel] various admin server stuff In-Reply-To: <4ACE5455.60601@redhat.com> References: <4ACE3173.3010105@redhat.com> <4ACE488E.5060505@redhat.com> <4ACE4BC0.3090408@redhat.com> <4ACE4FCA.2080506@redhat.com> <4ACE5268.6070806@redhat.com> <4ACE5455.60601@redhat.com> Message-ID: <4ACF63CB.7060008@redhat.com> Nathan Kinder wrote: > On 10/08/2009 01:58 PM, Rich Megginson wrote: >> Nathan Kinder wrote: >>> On 10/08/2009 01:29 PM, Rich Megginson wrote: >>>> Nathan Kinder wrote: >>>>> On 10/08/2009 11:37 AM, Rich Megginson wrote: >>>>>> I'd like to move mod_admserv and mod_restartd into the admin.git >>>>>> repo as sub-directories. I couldn't figure out a way to migrate >>>>>> the CVS history data into a git subdirectory, so I was thinking >>>>>> about just copying the files in there with no history. Is this >>>>>> ok? We can always refer back to the old CVS repo if we need to >>>>>> see history. >>>>> I think this is fine. As you say, we can always look at the old >>>>> CVS repo if needed. Done. admin server 1.1.10 and later has mod_admserv and mod_restartd in the source tree. >>>>>> >>>>>> It turns out we can't get rid of mod_restartd and use >>>>>> mod_suexec. mod_suexec explicitly forbids running CGIs as root, >>>>>> so we can't use that to start the servers. I don't really like >>>>>> the fact that we have to support this module for the sole purpose >>>>>> of being able to remotely start, restart, and create instances of >>>>>> servers that run on low ports. For one, mod_restartd is and >>>>>> always will be a security nightmare waiting to happen - it is >>>>>> just a bad, bad idea to execute CGIs as root (or run the admin >>>>>> server as root). >>>>> Agreed. We can mitigate the risk some by constraining things with >>>>> SELinux policy. >>>>>> For another, usually init or something like daemontools does a >>>>>> much better job of making sure remote servers are running (e.g. >>>>>> restarting after a crash). You always have to run >>>>>> setup-ds-admin.pl when installing on a remote system, and that >>>>>> creates the directory server instance, so I'm not really sure how >>>>>> useful it is to be able to remotely create instances. I'd like >>>>>> to propose that we make this feature optional (that is, can build >>>>>> admin server without it) and possibly get rid of it altogether. >>>>> It doesn't seem too common for people to run multiple instances on >>>>> the same system out in the wild. Even for those who do, I would >>>>> imagine that instance creation is not a common occurrence, and >>>>> this would really only affect Console users. This would mean that >>>>> changes are needed to Console to get rid of the "Create Instance" >>>>> task though. I'll work on this later. For now, it's easy to edit admserv.conf to disable this. >>>>>> >>>>>> I would also like to relax the requirement that we have to use >>>>>> the threaded model Apache. The only reason we require this is >>>>>> because mod_admserv caches the auth credentials and ACIs in >>>>>> memory, in case you need to perform a task while the config DS is >>>>>> down (e.g. like start or restart). There are a few changes >>>>>> required to mod_admserv to relax this restriction. >>>>> If the threaded model is not used, does that mean you can't >>>>> perform tasks when the config DS is down, even with the changes >>>>> you have in mind? >>>> You would not be able to perform CGI based tasks, such as - manage >>>> certs, view logs, stop/start/restart, create instance - and you >>>> would be able to do very few, if any, admin server web or console >>>> tasks. >>>> >>>> The other way to do it would be to run apache in prefork mode, but >>>> just have one server process (set the number of servers to fork to >>>> 1). Then you could use the prefork apache, with no threading, but >>>> still have the cache available. I've changed admin server - it will detect if the given apache binary has threading support. If not, configure will error. If you want to use a non-threaded Apache, you must specify the --disable-threading flag to configure. In addition, mod_admserv will print a Notice to the error log if a non-threaded Apache is being used. >>> This sounds best to me. Is there any real need for multiple >>> processes here? It's not like the admin server should be dealing >>> with tons of requests from different clients. The use case is >>> really one administrator using console (or Admin Express) to manage >>> their Directory Severs. Is there some other benefit we lose by >>> moving to a single process with no threading that I'm not thinking of? >> Gateway/phonebook/org chart - the default is to run these through the >> primary admin server - those apps are stateless/cacheless and would >> work just fine under plain old apache, regardless of the worker model. > So we could just recommend that those apps not be run under Admin > Server in production environments for performance reasons, but instead > run them under plain Apache webserver and configure as the admin sees fit. This will require a little work to make them work with a standalone Apache, not much, some in the setup script, some in the build. >>>> If you have more than one process, each one will have a separate >>>> cache, which may or may not contain the current auth and ACI cache, >>>> so it will just be luck to have the correct apache process with the >>>> correct cache serve your request. Of course we could move to a >>>> model where the cache is stored in shared memory, or disk file with >>>> flock/lockf access, or some other IPC model, but that seems like a >>>> lot of work for little benefit. >>> Yeah, too much work for no real benefit IMHO. >>>> The whole point of this is to mitigate the effect of a downed >>>> config DS, and some other method should be used to ensure that the >>>> config DS is always available (e.g. init/daemontools - see above). >>> One point to bring up here is that it may be preferable to not use >>> your config DS for anything other than being the config DS. This >>> would mean most people would want to create a second instance on the >>> same system, which they would only be able to do with >>> setup-ds-admin.pl if we pull that capability out of the >>> Console/CGI. I don't think that is a big deal though. >> You can already use setup-ds-admin.pl to create another instance. >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> -- >>>>>> 389-devel mailing list >>>>>> 389-devel at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> -- >>>>> 389-devel mailing list >>>>> 389-devel at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> -- >>>> 389-devel mailing list >>>> 389-devel at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> 389-devel mailing list >>> 389-devel at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >>> >> >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > > ------------------------------------------------------------------------ > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Thu Oct 15 21:22:00 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 15 Oct 2009 14:22:00 -0700 Subject: [389-devel] Please Review: Expose dirsrv SELinux policy interface Message-ID: <4AD79278.2010305@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Expose-dirsrv-SELinux-policy-interface.patch URL: From nhosoi at redhat.com Thu Oct 15 22:26:19 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 15 Oct 2009 15:26:19 -0700 Subject: [389-devel] Please Review: Expose dirsrv SELinux policy interface In-Reply-To: <4AD79278.2010305@redhat.com> References: <4AD79278.2010305@redhat.com> Message-ID: <4AD7A18B.9020808@redhat.com> On 10/15/2009 02:22 PM, Nathan Kinder wrote: > > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > ack. --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 Thu Oct 15 23:02:41 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 15 Oct 2009 16:02:41 -0700 Subject: [389-devel] Please Review: Expose dirsrv SELinux policy interface In-Reply-To: <4AD7A18B.9020808@redhat.com> References: <4AD79278.2010305@redhat.com> <4AD7A18B.9020808@redhat.com> Message-ID: <4AD7AA11.1030402@redhat.com> On 10/15/2009 03:26 PM, Noriko Hosoi wrote: > On 10/15/2009 02:22 PM, Nathan Kinder wrote: >> >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > ack. > --noriko Thanks for the review! Pushed to master. Counting objects: 17, done. Delta compression using 2 threads. Compressing objects: 100% (8/8), done. Writing objects: 100% (9/9), 1.64 KiB, done. Total 9 (delta 6), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git d121431..d7b1c99 master -> master > ------------------------------------------------------------------------ > > -- > 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 Oct 22 21:57:59 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 22 Oct 2009 14:57:59 -0700 Subject: [389-devel] Please Review: Extend dirsrv SELinux policy interface Message-ID: <4AE0D567.9030306@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Extend-dirsrv-SELinux-policy-interface.patch URL: From nkinder at redhat.com Thu Oct 22 21:58:33 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 22 Oct 2009 14:58:33 -0700 Subject: [389-devel] Please Review: Add SELinux policy module for Admin Server Message-ID: <4AE0D589.2060709@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Add-SELinux-policy-module-for-Admin-Server.patch URL: From nhosoi at redhat.com Thu Oct 22 22:22:04 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 22 Oct 2009 15:22:04 -0700 Subject: [389-devel] Please Review: Extend dirsrv SELinux policy interface In-Reply-To: <4AE0D567.9030306@redhat.com> References: <4AE0D567.9030306@redhat.com> Message-ID: <4AE0DB0C.6010606@redhat.com> On 10/22/2009 02:57 PM, Nathan Kinder wrote: > > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > ack. --noriko -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhosoi at redhat.com Thu Oct 22 22:28:40 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 22 Oct 2009 15:28:40 -0700 Subject: [389-devel] Please Review: Add SELinux policy module for Admin Server In-Reply-To: <4AE0D589.2060709@redhat.com> References: <4AE0D589.2060709@redhat.com> Message-ID: <4AE0DC98.4060702@redhat.com> On 10/22/2009 02:58 PM, Nathan Kinder wrote: > > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > ack. --noriko -------------- next part -------------- An HTML attachment was scrubbed... URL: From nkinder at redhat.com Thu Oct 22 22:47:08 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 22 Oct 2009 15:47:08 -0700 Subject: [389-devel] Please Review: Extend dirsrv SELinux policy interface In-Reply-To: <4AE0DB0C.6010606@redhat.com> References: <4AE0D567.9030306@redhat.com> <4AE0DB0C.6010606@redhat.com> Message-ID: <4AE0E0EC.4050800@redhat.com> On 10/22/2009 03:22 PM, Noriko Hosoi wrote: > On 10/22/2009 02:57 PM, Nathan Kinder wrote: >> >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > ack. > --noriko Thanks. Pushed to master. Counting objects: 7, done. Delta compression using 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 655 bytes, done. Total 4 (delta 3), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git d7b1c99..41fa124 master -> master > ------------------------------------------------------------------------ > > -- > 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 Oct 22 22:51:31 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 22 Oct 2009 15:51:31 -0700 Subject: [389-devel] Please Review: Add SELinux policy module for Admin Server In-Reply-To: <4AE0DC98.4060702@redhat.com> References: <4AE0D589.2060709@redhat.com> <4AE0DC98.4060702@redhat.com> Message-ID: <4AE0E1F3.8040100@redhat.com> On 10/22/2009 03:28 PM, Noriko Hosoi wrote: > On 10/22/2009 02:58 PM, Nathan Kinder wrote: >> >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > ack. > --noriko Thanks. Pushed to master. Counting objects: 32, done. Delta compression using 2 threads. Compressing objects: 100% (18/18), done. Writing objects: 100% (19/19), 7.09 KiB, done. Total 19 (delta 13), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/admin.git 928e651..60162ee master -> master > ------------------------------------------------------------------------ > > -- > 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 Oct 26 20:10:28 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 26 Oct 2009 13:10:28 -0700 Subject: [389-devel] Please Review: (221905) Add SMD5 password storage support Message-ID: <4AE60234.7060704@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-BZ-221905-Add-SMD5-password-storage-support.patch URL: From nhosoi at redhat.com Mon Oct 26 20:20:50 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 26 Oct 2009 13:20:50 -0700 Subject: [389-devel] Please Review: (221905) Add SMD5 password storage support In-Reply-To: <4AE60234.7060704@redhat.com> References: <4AE60234.7060704@redhat.com> Message-ID: <4AE604A2.8050709@redhat.com> On 10/26/2009 01:10 PM, Nathan Kinder wrote: > > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > ack. --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: 6646 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Oct 26 20:28:25 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 26 Oct 2009 14:28:25 -0600 Subject: [389-devel] Please Review: (221905) Add SMD5 password storage support In-Reply-To: <4AE60234.7060704@redhat.com> References: <4AE60234.7060704@redhat.com> Message-ID: <4AE60669.9060707@redhat.com> Nathan Kinder wrote: > > ------------------------------------------------------------------------ > > -- > 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 Mon Oct 26 22:19:55 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Mon, 26 Oct 2009 15:19:55 -0700 Subject: [389-devel] Please Review: (221905) Add SMD5 password storage support In-Reply-To: <4AE604A2.8050709@redhat.com> References: <4AE60234.7060704@redhat.com> <4AE604A2.8050709@redhat.com> Message-ID: <4AE6208B.5030609@redhat.com> On 10/26/2009 01:20 PM, Noriko Hosoi wrote: > On 10/26/2009 01:10 PM, Nathan Kinder wrote: >> >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > ack. > --noriko Thanks for the reviews! Pushed to master. Counting objects: 36, done. Delta compression using 2 threads. Compressing objects: 100% (19/19), done. Writing objects: 100% (20/20), 5.26 KiB, done. Total 20 (delta 15), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 41fa124..333c980 master -> master > ------------------------------------------------------------------------ > > -- > 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 Tue Oct 27 23:09:44 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 27 Oct 2009 16:09:44 -0700 Subject: [389-devel] Please Review: Remove blank line from 00core.ldif Message-ID: <4AE77DB8.1080501@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Remove-blank-line-from-00core.ldif.patch URL: From nhosoi at redhat.com Tue Oct 27 23:11:18 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Tue, 27 Oct 2009 16:11:18 -0700 Subject: [389-devel] Please Review: Remove blank line from 00core.ldif In-Reply-To: <4AE77DB8.1080501@redhat.com> References: <4AE77DB8.1080501@redhat.com> Message-ID: <4AE77E16.5000802@redhat.com> On 10/27/2009 04:09 PM, Nathan Kinder wrote: > > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > ack. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6646 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Tue Oct 27 23:13:01 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 27 Oct 2009 16:13:01 -0700 Subject: [389-devel] Please Review: Remove blank line from 00core.ldif In-Reply-To: <4AE77E16.5000802@redhat.com> References: <4AE77DB8.1080501@redhat.com> <4AE77E16.5000802@redhat.com> Message-ID: <4AE77E7D.1090808@redhat.com> On 10/27/2009 04:11 PM, Noriko Hosoi wrote: > On 10/27/2009 04:09 PM, Nathan Kinder wrote: >> >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > ack. Thanks. Pushed to master. Counting objects: 9, done. Delta compression using 2 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 635 bytes, done. Total 5 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 333c980..de63856 master -> master > ------------------------------------------------------------------------ > > -- > 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 kolesov_dv at mail.ru Tue Oct 27 23:29:56 2009 From: kolesov_dv at mail.ru (Dmitry Kolesov) Date: Wed, 28 Oct 2009 02:29:56 +0300 Subject: [389-devel] Introduction Message-ID: Hello. My name is Dmitry Kolesov and I would like to contribute to the Directory Server project. I have experience with C/C++, bash, Python, PHP, MySQL, PostgreSQL. I use Directory Server in my work and I would like to help in development it. My Fedora Account and account in irc is kolesovdv. Best regards. From andrey.ivanov at polytechnique.fr Wed Oct 28 08:19:13 2009 From: andrey.ivanov at polytechnique.fr (Andrey Ivanov) Date: Wed, 28 Oct 2009 09:19:13 +0100 Subject: [389-devel] Introduction In-Reply-To: References: Message-ID: <1601b8650910280119u1f28b012ude8f2f8c76280f6e@mail.gmail.com> Hi, The server is written in C. So your C experience may be helpful. The scripts around the server are mainly perl- and bash-based. The management console is written in Java. The database backend is Berkley DB. You can start from this page in order to see how you can contribute to the server development : http://directory.fedoraproject.org/wiki/How_to_contribute You may also be interested in looking at the roadmap http://directory.fedoraproject.org/wiki/Roadmap The current bugs/requested features are mainly listed in bugzilla https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&product=389&cmdtype=doitand on the wishlist http://directory.fedoraproject.org/wiki/Wishlist You are also welcome to make your suggestions and help others on this mailing list. It's up to you how you prefer to contribute - test the latest builds/add features/resolve bugs/participate in the mailing lists/other... @+ 2009/10/28 Dmitry Kolesov > Hello. > > My name is Dmitry Kolesov and I would like to contribute to the Directory > Server project. > > I have experience with C/C++, bash, Python, PHP, MySQL, PostgreSQL. > I use Directory Server in my work and I would like to help in development > it. > > My Fedora Account and account in irc is kolesovdv. > > > Best regards. > > -- > 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 Oct 29 01:25:33 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 28 Oct 2009 18:25:33 -0700 Subject: [389-devel] Please Review: (529258) Make upgrade remove obsolete schema from 99user.ldif Message-ID: <4AE8EF0D.9070903@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Bug-529258-Make-upgrade-remove-obsolete-schema-fro.patch URL: From nhosoi at redhat.com Thu Oct 29 01:40:41 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Wed, 28 Oct 2009 18:40:41 -0700 Subject: [389-devel] Please Review: (529258) Make upgrade remove obsolete schema from 99user.ldif In-Reply-To: <4AE8EF0D.9070903@redhat.com> References: <4AE8EF0D.9070903@redhat.com> Message-ID: <4AE8F299.2090901@redhat.com> An HTML attachment was scrubbed... URL: From nkinder at redhat.com Thu Oct 29 01:52:20 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 28 Oct 2009 18:52:20 -0700 Subject: [389-devel] Please Review: (529258) Make upgrade remove obsolete schema from 99user.ldif In-Reply-To: <4AE8F299.2090901@redhat.com> References: <4AE8EF0D.9070903@redhat.com> <4AE8F299.2090901@redhat.com> Message-ID: <4AE8F554.9080306@redhat.com> On 10/28/2009 06:40 PM, Noriko Hosoi wrote: > Nathan Kinder wrote: >> ------------------------------------------------------------------------ >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel > ack. with one typo... ;) Doh! Thanks! Pushed to master (with corrected typo). Counting objects: 15, done. Delta compression using 2 threads. Compressing objects: 100% (7/7), done. Writing objects: 100% (8/8), 2.75 KiB, done. Total 8 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git de63856..f4eae7f master -> master > > @@ -45,6 +173,13 @@ sub runinst { > next if (-f $newname); # not removed > rename $oldname, $newname; > } > + > + # Restore 99user.ldif. We overwrite whatever is there since > + # it is possible that we have modifed it. > > ------------------------------------------------------------------------ > > -- > 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 kolesov_dv at mail.ru Thu Oct 29 13:53:46 2009 From: kolesov_dv at mail.ru (Dmitry Kolesov) Date: Thu, 29 Oct 2009 16:53:46 +0300 Subject: =?koi8-r?Q?Re=3A_[389-devel]_Introduction?= Message-ID: Hello. Can I get this task: "Support links between two attributes (like memberOf but with other/configurable attributes)"? (http://directory.fedoraproject.org/wiki/Linked_Attributes_Design). Who can I ask questions if I need more details of this task in IRC? -Dmitry @+ -----Original Message----- From: Andrey Ivanov > Hi, > > The server is written in C. So your C experience may be helpful. The scripts > around the server are mainly perl- and bash-based. The management console is > written in Java. The database backend is Berkley DB. You can start from this > page in order to see how you can contribute to the server development : > http://directory.fedoraproject.org/wiki/How_to_contribute > > You may also be interested in looking at the roadmap > http://directory.fedoraproject.org/wiki/Roadmap > > The current bugs/requested features are mainly listed in bugzilla > https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&product=389&cmdtype=doitand > on the wishlist > http://directory.fedoraproject.org/wiki/Wishlist > > You are also welcome to make your suggestions and help others on this > mailing list. > > It's up to you how you prefer to contribute - test the latest builds/add > features/resolve bugs/participate in the mailing lists/other... From rmeggins at redhat.com Thu Oct 29 17:11:32 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 29 Oct 2009 11:11:32 -0600 Subject: [389-devel] Introduction In-Reply-To: References: Message-ID: <4AE9CCC4.1060309@redhat.com> Dmitry Kolesov wrote: > Hello. > > My name is Dmitry Kolesov and I would like to contribute to the Directory Server project. > Great! Glad to have you on board. > I have experience with C/C++, bash, Python, PHP, MySQL, PostgreSQL. > I use Directory Server in my work and I would like to help in development it. > What areas are you interested in? Is there any functionality you would like to see or use that is not currently in the project? > My Fedora Account and account in irc is kolesovdv. > > > Best regards. > > -- > 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 Thu Oct 29 17:12:25 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 29 Oct 2009 11:12:25 -0600 Subject: [389-devel] Introduction In-Reply-To: References: Message-ID: <4AE9CCF9.7060304@redhat.com> Dmitry Kolesov wrote: > Hello. > > Can I get this task: "Support links between two attributes (like memberOf but with other/configurable attributes)"? > (http://directory.fedoraproject.org/wiki/Linked_Attributes_Design). > It has already been done - http://directory.fedoraproject.org/wiki/Roadmap#Version_1.2.1 > Who can I ask questions if I need more details of this task in IRC? > Just ask in #389 - someone will be around > -Dmitry > > @+ > -----Original Message----- > From: Andrey Ivanov > >> Hi, >> >> The server is written in C. So your C experience may be helpful. The scripts >> around the server are mainly perl- and bash-based. The management console is >> written in Java. The database backend is Berkley DB. You can start from this >> page in order to see how you can contribute to the server development : >> http://directory.fedoraproject.org/wiki/How_to_contribute >> >> You may also be interested in looking at the roadmap >> http://directory.fedoraproject.org/wiki/Roadmap >> >> The current bugs/requested features are mainly listed in bugzilla >> https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&product=389&cmdtype=doitand >> on the wishlist >> http://directory.fedoraproject.org/wiki/Wishlist >> >> You are also welcome to make your suggestions and help others on this >> mailing list. >> >> It's up to you how you prefer to contribute - test the latest builds/add >> features/resolve bugs/participate in the mailing lists/other... >> > > -- > 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 Thu Oct 29 22:12:17 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 29 Oct 2009 15:12:17 -0700 Subject: [389-devel] Please Review: Remove instance initconfig script when removing an instance Message-ID: <4AEA1341.3020200@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-Make-removeds.pl-remove-instance-initconfig-script.patch URL: From nhosoi at redhat.com Thu Oct 29 22:18:11 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Thu, 29 Oct 2009 15:18:11 -0700 Subject: [389-devel] Please Review: Remove instance initconfig script when removing an instance In-Reply-To: <4AEA1341.3020200@redhat.com> References: <4AEA1341.3020200@redhat.com> Message-ID: <4AEA14A3.8030305@redhat.com> On 10/29/2009 03:12 PM, Nathan Kinder wrote: > > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > ack. --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: 6646 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Thu Oct 29 22:31:26 2009 From: jdennis at redhat.com (John Dennis) Date: Thu, 29 Oct 2009 18:31:26 -0400 Subject: [389-devel] Please Review: Remove instance initconfig script when removing an instance In-Reply-To: <4AEA1341.3020200@redhat.com> References: <4AEA1341.3020200@redhat.com> Message-ID: <4AEA17BE.6000607@redhat.com> Hmm... leaving an init script around after package removal is a bug I recently reported against dogtag (Certificate Management System). Init scripts should be an actual file belonging to the rpm listed in the %files section of the rpm spec file. In dogtag the init script was being dynamically generated when the rpm was installed. That's not good for two reasons, one is the init script should be available for review and inspection, secondly it's a critical file which is not known to rpm nor is it possible for rpm to accord it config status with special config handing. I have not looked at the 389 installation scripts or spec file but this patch suggests 389 is doing the same thing dogtag is. Is 389 hiding it's init script in a perl generation step at installation? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From nkinder at redhat.com Thu Oct 29 22:38:04 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 29 Oct 2009 15:38:04 -0700 Subject: [389-devel] Please Review: Remove instance initconfig script when removing an instance In-Reply-To: <4AEA17BE.6000607@redhat.com> References: <4AEA1341.3020200@redhat.com> <4AEA17BE.6000607@redhat.com> Message-ID: <4AEA194C.8020009@redhat.com> On 10/29/2009 03:31 PM, John Dennis wrote: > Hmm... leaving an init script around after package removal is a bug I > recently reported against dogtag (Certificate Management System). > > Init scripts should be an actual file belonging to the rpm listed in > the %files section of the rpm spec file. Out initconfig script (/etc/sysconfig/dirsrv) is a part of the package, as is our init script (/etc/rc.d/init.d/dirsrv). The files that this patch is referring to are instance specific initconfig scripts. An instance is created after the RPM is installed, and hence can't be owned by the package itself. > In dogtag the init script was being dynamically generated when the rpm > was installed. That's not good for two reasons, one is the init script > should be available for review and inspection, secondly it's a > critical file which is not known to rpm nor is it possible for rpm to > accord it config status with special config handing. > > I have not looked at the 389 installation scripts or spec file but > this patch suggests 389 is doing the same thing dogtag is. Is 389 > hiding it's init script in a perl generation step at installation? Nope. It's a file generated at build time and is static once packaged. The file we are referring to is sourced by the init script to set some instance speficic paths. A example looks like this: SERVER_DIR=/usr/lib/dirsrv ; export SERVER_DIR SERVERBIN_DIR=/usr/sbin ; export SERVERBIN_DIR CONFIG_DIR=/etc/dirsrv/slapd-foo ; export CONFIG_DIR INST_DIR=/usr/lib/dirsrv/slapd-foo ; export INST_DIR RUN_DIR=/var/run/dirsrv ; export RUN_DIR DS_ROOT= ; export DS_ROOT PRODUCT_NAME=slapd ; export PRODUCT_NAME From rmeggins at redhat.com Thu Oct 29 22:40:06 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 29 Oct 2009 16:40:06 -0600 Subject: [389-devel] Please Review: Remove instance initconfig script when removing an instance In-Reply-To: <4AEA17BE.6000607@redhat.com> References: <4AEA1341.3020200@redhat.com> <4AEA17BE.6000607@redhat.com> Message-ID: <4AEA19C6.6020802@redhat.com> John Dennis wrote: > Hmm... leaving an init script around after package removal is a bug I > recently reported against dogtag (Certificate Management System). > > Init scripts should be an actual file belonging to the rpm listed in > the %files section of the rpm spec file. In dogtag the init script was > being dynamically generated when the rpm was installed. That's not > good for two reasons, one is the init script should be available for > review and inspection, secondly it's a critical file which is not > known to rpm nor is it possible for rpm to accord it config status > with special config handing. > > I have not looked at the 389 installation scripts or spec file but > this patch suggests 389 is doing the same thing dogtag is. Is 389 > hiding it's init script in a perl generation step at installation? > This is more of a config file than an init script. -------------- 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 Oct 29 22:39:39 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 29 Oct 2009 15:39:39 -0700 Subject: [389-devel] Please Review: Remove instance initconfig script when removing an instance In-Reply-To: <4AEA14A3.8030305@redhat.com> References: <4AEA1341.3020200@redhat.com> <4AEA14A3.8030305@redhat.com> Message-ID: <4AEA19AB.2000102@redhat.com> On 10/29/2009 03:18 PM, Noriko Hosoi wrote: > On 10/29/2009 03:12 PM, Nathan Kinder wrote: >> >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > ack. > --noriko Thanks for the review! Pushed to master. Counting objects: 13, done. Delta compression using 2 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (7/7), 704 bytes, done. Total 7 (delta 5), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 835c647..b626349 master -> master > ------------------------------------------------------------------------ > > -- > 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 Oct 30 15:46:13 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 30 Oct 2009 08:46:13 -0700 Subject: [389-devel] Please Review: (529909) Update SELinux policy for SASL GSSAPI Message-ID: <4AEB0A45.8000804@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-529909-Update-SELinux-policy-for-SASL-GSSAPI.patch URL: From nhosoi at redhat.com Fri Oct 30 15:51:49 2009 From: nhosoi at redhat.com (Noriko Hosoi) Date: Fri, 30 Oct 2009 08:51:49 -0700 Subject: [389-devel] Please Review: (529909) Update SELinux policy for SASL GSSAPI In-Reply-To: <4AEB0A45.8000804@redhat.com> References: <4AEB0A45.8000804@redhat.com> Message-ID: <4AEB0B95.20405@redhat.com> On 10/30/2009 08:46 AM, Nathan Kinder wrote: > > > -- > 389-devel mailing list > 389-devel at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-devel > ack. --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: 6646 bytes Desc: S/MIME Cryptographic Signature URL: From nkinder at redhat.com Fri Oct 30 15:55:05 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Fri, 30 Oct 2009 08:55:05 -0700 Subject: [389-devel] Please Review: (529909) Update SELinux policy for SASL GSSAPI In-Reply-To: <4AEB0B95.20405@redhat.com> References: <4AEB0A45.8000804@redhat.com> <4AEB0B95.20405@redhat.com> Message-ID: <4AEB0C59.1080404@redhat.com> On 10/30/2009 08:51 AM, Noriko Hosoi wrote: > On 10/30/2009 08:46 AM, Nathan Kinder wrote: >> >> >> -- >> 389-devel mailing list >> 389-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel >> > ack. > --noriko Thanks! Pushed to master. Counting objects: 7, done. Delta compression using 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (4/4), 647 bytes, done. Total 4 (delta 3), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git b626349..027e8a4 master -> master > ------------------------------------------------------------------------ > > -- > 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 yzhang at redhat.com Fri Oct 30 21:56:49 2009 From: yzhang at redhat.com (yi zhang) Date: Fri, 30 Oct 2009 14:56:49 -0700 Subject: [389-devel] Please Review: {459181} add option to ldlct to accept "-e attreplacefile=" Message-ID: <4AEB6121.9050706@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 0001-459181-Add-attreplacefile-option-to-ldclt.patch URL: From kolesov_dv at mail.ru Fri Oct 30 16:50:01 2009 From: kolesov_dv at mail.ru (Dmitry Kolesov) Date: Fri, 30 Oct 2009 19:50:01 +0300 Subject: =?koi8-r?Q?Re=3A_[389-devel]_Introduction?= In-Reply-To: <4AE9CCC4.1060309@redhat.com> References: <4AE9CCC4.1060309@redhat.com> Message-ID: Rich Megginson wrote: > What areas are you interested in? Is there any functionality you would > like to see or use that is not currently in the project? At first, I'd like to start with Console Features. What can I do to help you? -Dmitry