From sacadmin Tue Jun 2 10:15:33 2009 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n52HFXAM026153; Tue, 2 Jun 2009 10:15:33 -0700 (PDT) Received: (from dr146992@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n52HFXUH026149; Tue, 2 Jun 2009 10:15:33 -0700 (PDT) Date: Tue, 2 Jun 2009 10:15:33 -0700 (PDT) From: Darren Reed Message-Id: <200906021715.n52HFXUH026149@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: resource project for inetd [PSARC/2009/332 FastTrack] Status: RO Content-Length: 558 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: resource project for inetd 1.2. Name of Document Author/Supplier: Author: DArren Reed 1.3 Date of This Document: 02 June, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Reed@sun.com Wed Jun 3 07:02:23 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53E2N7v010136 for ; Wed, 3 Jun 2009 07:02:23 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n53E2KNd005546 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Jun 2009 07:02:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00A0F1NZDY00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 07:02:23 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO00IJI1NUMD80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 07:02:19 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n53E2IK3018178 for ; Wed, 03 Jun 2009 14:02:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKO006001E2S200@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:02:18 +0100 (BST) Received: from [129.157.18.122] ([unknown] [129.157.18.122]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKO00EL61NK7HD0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:02:08 +0100 (BST) Date: Wed, 03 Jun 2009 16:02:04 +0200 From: Darren Reed Subject: PSARC/2009/332 New projects with boundless resources Sender: Darren.Reed@sun.com To: PSARC-EXT Message-id: <4A26825C.9000807@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 3387 I'm sponsoring this fast track for myself. PSARC admin ========== I tried to rename the case but: bin/sac_rename_title PSARC/2009/332 "New projects with boundless resources" ERROR: Could not find "PSARC/2009/332" in SAC Database files. ....maybe I'm driving the tools incorrectly? ... ...the case... This project seeks micro/patch binding. Problem ======= The /etc/project file has been delivered (PSARC/1999/119) but its delivery did not define how we would add and name new projects, only that the numbers less than 100 were reserved. In addition, it did not offer full support of the features found in the project utilities such as prctl(1). Namespace ========= Now that the file has been shipped for a number of years, we need to make reasonable guesses about what customers may have done since its delivery. One such guess is that they may have created projects with names similar or the same as SMF FMRIs or executables with which they are associated. Thus in creating a new project to be shipped by default, using a name such as "login" or "init" or "inetd" cannot be considered to be without risk. To provide us with the required flexibility for future enginering, this case proposes that all project names starting with "SUNW" be reserved and that they are not to be used by customers to define their own projects. This limitation needs to be documented in updates to project(4) and projadd(1M). Removing Limits =============== Using prctl(1), it is possible (depending on your privileges) to add, change or remove resource limits associated with projects. When using projadd(1M), it is only possible to define projects in terms of new limits they will have: it is not possible to remove an inherited resource limit using a project definition in /etc/project. Thus this case would like to propose that the /etc/project file be extended to allow resource limits to be removed. The suggested syntax is to simply be '=removed'. As an example, it would be possible to use "project.max-contracts=removed". Implementation ============== This cases proposes to implement the above suggestions and to deliver the following changes to the existing platform. New Project ~~~~~~~~~~~ This case will deliver a new project called "SUNWinetd" that will be added to /etc/project. The line to be added is: SUNWinetd:5::::project.max-contracts=remove svc:/network/inetd:default ~~~~~~~~~~~~~~~~~~~~~~~~~~ The manifest for svc:/network/inetd:default will be updated to define the default inetd SMF service as a member of the SUNWinetd project. Discussion ========== It is reasonable to ask the question if one daemon has a resource control problem, isn't it likely others will and thus isn't the inetd problem being solved more generic? To answer that question, it behooves us to recognise that inetd is a rather special daemon and in SMF parlance, it is also in a special cateogry - "restarter". The problem being investigated here (6271923) is particular to inetd in specific workload testing. Whilst we shouldn't be engineering the system to require tuning, removing limits for all processes removes the protection the limits offer, see PSARC/2004/xxx. In this regard, the best course of action is for project teams to analyse and understand the execution profiles that their daemons are likely to have and deliver special project defintions as required. From Darren.Moffat@sun.com Wed Jun 3 07:13:07 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53ED6VU010184 for ; Wed, 3 Jun 2009 07:13:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n53ED3lb027777 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Jun 2009 22:13:06 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00F1525S8000@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 08:13:04 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO009ES25Q3460@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 08:13:03 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n53ED2mM001152 for ; Wed, 03 Jun 2009 14:13:02 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKO007000EGG600@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 15:13:02 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKO00DG425NDT70@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 15:12:59 +0100 (BST) Date: Wed, 03 Jun 2009 15:12:59 +0100 From: Darren J Moffat Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A26825C.9000807@Sun.COM> Sender: Darren.Moffat@sun.com To: Darren Reed Cc: PSARC-EXT Message-id: <4A2684EB.1070506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 91 Rather than SUNW as a prefix why not "org.opensolaris." or "com.sun" ? -- Darren J Moffat From carlsonj@phorcys.east.sun.com Wed Jun 3 07:21:56 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53ELtNt010202 for ; Wed, 3 Jun 2009 07:21:55 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n53ELm5o016703 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Wed, 3 Jun 2009 15:21:54 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00D0B2KFW000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 07:21:51 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO00ISK2KDMDA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 07:21:50 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n53ELnRl044368; Wed, 03 Jun 2009 10:21:49 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n53EKeao011861; Wed, 03 Jun 2009 10:20:40 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n53EKeRS011858; Wed, 03 Jun 2009 10:20:40 -0400 (EDT) Date: Wed, 03 Jun 2009 10:20:40 -0400 From: James Carlson Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A2684EB.1070506@Sun.COM> To: Darren J Moffat Cc: Darren Reed , PSARC-EXT Message-id: <18982.34488.509418.329752@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> Status: RO Content-Length: 526 Darren J Moffat writes: > Rather than SUNW as a prefix why not "org.opensolaris." or "com.sun" ? Tradition? I doubt the exact character sequence for the prefix matters, though. Something pity, simple, and unlikely to overlap anything any semi-sane administrator would ever use should be good enough. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Reed@sun.com Wed Jun 3 07:22:02 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53EM2QN010252 for ; Wed, 3 Jun 2009 07:22:02 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n53ELvhc022175 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Jun 2009 07:22:01 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00G072KO1U00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 08:22:00 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO0096P2KN3670@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 08:22:00 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n53ELxeH021678 for ; Wed, 03 Jun 2009 14:21:59 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKO00L001NIY200@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 15:21:59 +0100 (BST) Received: from [129.157.18.122] ([unknown] [129.157.18.122]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKO00FGD2K5LFD0@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 15:21:42 +0100 (BST) Date: Wed, 03 Jun 2009 16:21:36 +0200 From: Darren Reed Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A2684EB.1070506@Sun.COM> Sender: Darren.Reed@sun.com To: Darren J Moffat Cc: PSARC-EXT Message-id: <4A2686F0.6070109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 306 Darren J Moffat wrote: > Rather than SUNW as a prefix why not "org.opensolaris." or "com.sun" ? I've no strong opinion about this ... do we have some internal structure for such names? "com.sun.inetd" seems too.... "broad" for my liking... "com.sun.solaris.inetd" might be a better/tighter fit. Darren From Darren.Moffat@sun.com Wed Jun 3 07:23:52 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53ENpww010294 for ; Wed, 3 Jun 2009 07:23:51 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n53ENlDs003500 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Jun 2009 22:23:50 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00H0H2NNX800@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 07:23:47 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO00HAG2NL8A20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 07:23:46 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n53ENjaN022021 for ; Wed, 03 Jun 2009 14:23:45 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKO00G002LO5U00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:23:45 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKO00D4K2NFDT80@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:23:39 +0100 (BST) Date: Wed, 03 Jun 2009 15:23:39 +0100 From: Darren J Moffat Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A2686F0.6070109@Sun.COM> Sender: Darren.Moffat@sun.com To: Darren Reed Cc: PSARC-EXT Message-id: <4A26876B.7000907@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 441 Darren Reed wrote: > Darren J Moffat wrote: >> Rather than SUNW as a prefix why not "org.opensolaris." or "com.sun" ? > > I've no strong opinion about this ... > do we have some internal structure for such names? > > "com.sun.inetd" seems too.... "broad" for my liking... > "com.sun.solaris.inetd" might be a better/tighter fit. or even just "solaris.inetd" which matches the hierarchy used for RBAC authorisations. -- Darren J Moffat From Nicolas.Williams@sun.com Wed Jun 3 07:27:27 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53ERQuV010446 for ; Wed, 3 Jun 2009 07:27:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n53ERDAd061977; Wed, 3 Jun 2009 08:27:23 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00I2Y2TK3T00@nwk-avmta-2.sfbay.sun.com>; Wed, 03 Jun 2009 07:27:20 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO00HUR2TJ8C20@nwk-avmta-2.sfbay.sun.com>; Wed, 03 Jun 2009 07:27:20 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n53EOtNQ026766; Wed, 03 Jun 2009 09:24:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n53EOte7026765; Wed, 03 Jun 2009 09:24:55 -0500 (CDT) Date: Wed, 03 Jun 2009 09:24:55 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <18982.34488.509418.329752@gargle.gargle.HOWL> To: James Carlson Cc: Darren J Moffat , Darren Reed , PSARC-EXT Message-id: <20090603142454.GE26728@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <18982.34488.509418.329752@gargle.gargle.HOWL> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 496 On Wed, Jun 03, 2009 at 10:20:40AM -0400, James Carlson wrote: > Darren J Moffat writes: > > Rather than SUNW as a prefix why not "org.opensolaris." or "com.sun" ? > > Tradition? > > I doubt the exact character sequence for the prefix matters, though. > Something pity, simple, and unlikely to overlap anything any semi-sane > administrator would ever use should be good enough. Either way, should this set precedent for other things? It can't really for passwd(4) and group(4) names, sadly. From Bart.Blanquart@sun.com Wed Jun 3 07:27:57 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53ERuMv010483 for ; Wed, 3 Jun 2009 07:27:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n53ERjJi020212 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Jun 2009 15:27:55 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00I0D2UI4T00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 07:27:54 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO00HWV2UH8C20@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 07:27:54 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n53ERr4x003733 for ; Wed, 03 Jun 2009 14:27:53 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKO00G002LO5U00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:27:53 +0100 (BST) Received: from [129.159.234.128] ([unknown] [129.159.234.128]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKO00DEV2UDDT80@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:27:49 +0100 (BST) Date: Wed, 03 Jun 2009 16:27:49 +0200 From: Bart Blanquart Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <18982.34488.509418.329752@gargle.gargle.HOWL> Sender: Bart.Blanquart@sun.com To: PSARC-EXT Reply-to: Bart.Blanquart@sun.com Message-id: <4A268865.2000007@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <18982.34488.509418.329752@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.19 (X11/20090110) Status: RO Content-Length: 402 On 06/03/09 16:20, James Carlson wrote: > Darren J Moffat writes: >> Rather than SUNW as a prefix why not "org.opensolaris." or "com.sun" ? > > Tradition? > > I doubt the exact character sequence for the prefix matters, though. > Something pity, simple, and unlikely to overlap anything any semi-sane > administrator would ever use should be good enough. > solaris.* (parity with auth_attr)? Bart From Menno.Lageman@Sun.COM Wed Jun 3 07:36:43 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53EahPT010658 for ; Wed, 3 Jun 2009 07:36:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n53EagqY024768 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Jun 2009 07:36:42 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00H03396GJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 08:36:42 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO009MY3953B80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 08:36:42 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n53Eafdh024218 for ; Wed, 03 Jun 2009 14:36:41 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKO00L002LAF200@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 15:36:41 +0100 (BST) Received: from [129.159.237.204] ([unknown] [129.159.237.204]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKO00M8P38Y0E90@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 03 Jun 2009 15:36:35 +0100 (BST) Date: Wed, 03 Jun 2009 16:36:44 +0200 From: Menno Lageman Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A26825C.9000807@Sun.COM> Sender: Menno.Lageman@Sun.COM To: Darren Reed Cc: PSARC-EXT Reply-to: Menno.Lageman@Sun.COM Message-id: <4A268A7C.7090802@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080531) Status: RO Content-Length: 3105 On 06/03/09 16:02, Darren Reed wrote: > I'm sponsoring this fast track for myself. > > PSARC admin > ========== > I tried to rename the case but: > bin/sac_rename_title PSARC/2009/332 "New projects with boundless resources" > > > ERROR: Could not find "PSARC/2009/332" in SAC Database files. > > > ....maybe I'm driving the tools incorrectly? ... > > ...the case... > > This project seeks micro/patch binding. > > Problem > ======= > The /etc/project file has been delivered (PSARC/1999/119) but its > delivery did not define how we would add and name new projects, > only that the numbers less than 100 were reserved. In addition, > it did not offer full support of the features found in the project > utilities such as prctl(1). > > Namespace > ========= > Now that the file has been shipped for a number of years, we need > to make reasonable guesses about what customers may have done since > its delivery. One such guess is that they may have created projects > with names similar or the same as SMF FMRIs or executables with which > they are associated. Thus in creating a new project to be shipped by > default, using a name such as "login" or "init" or "inetd" cannot be > considered to be without risk. > > To provide us with the required flexibility for future enginering, > this case proposes that all project names starting with "SUNW" be > reserved and that they are not to be used by customers to define > their own projects. This limitation needs to be documented in > updates to project(4) and projadd(1M). > > Removing Limits > =============== > Using prctl(1), it is possible (depending on your privileges) to > add, change or remove resource limits associated with projects. > When using projadd(1M), it is only possible to define projects in > terms of new limits they will have: it is not possible to remove > an inherited resource limit using a project definition in > /etc/project. > > Thus this case would like to propose that the /etc/project file > be extended to allow resource limits to be removed. The suggested > syntax is to simply be '=removed'. As an example, > it would be possible to use "project.max-contracts=removed". > > Implementation > ============== > This cases proposes to implement the above suggestions and to > deliver the following changes to the existing platform. > > New Project > ~~~~~~~~~~~ > This case will deliver a new project called "SUNWinetd" that will > be added to /etc/project. The line to be added is: > > SUNWinetd:5::::project.max-contracts=remove - How will this cope with multiple occurrences of a resource control in the project database? Taking the example from project(4) beatles:100:The Beatles:john,paul,george,ringo::task.max-lwps= (privileged,100,signal=SIGTERM),(privileged,110,deny); process.max-file-descriptor what would happen if one specified SUNWinetd:5::::task.max-lwps=remove ? - You specifically mention /etc/project, so I assume a network based project database isn't updated, right? Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno From Darren.Reed@Sun.COM Wed Jun 3 07:39:19 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53EdIh1010674 for ; Wed, 3 Jun 2009 07:39:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n53EcfGT011371 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Jun 2009 22:39:17 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00I0F3DFPP00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 07:39:15 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO00HAC3DD8A50@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 07:39:14 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n53EdDXg024606 for ; Wed, 03 Jun 2009 14:39:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKO006001E2S200@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:39:13 +0100 (BST) Received: from [129.157.18.122] ([unknown] [129.157.18.122]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKO009L83D2FXG0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:39:02 +0100 (BST) Date: Wed, 03 Jun 2009 16:38:57 +0200 From: Darren Reed Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A26876B.7000907@Sun.COM> Sender: Darren.Reed@Sun.COM To: Darren J Moffat Cc: PSARC-EXT Message-id: <4A268B01.8080905@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 1373 Darren J Moffat wrote: > Darren Reed wrote: >> Darren J Moffat wrote: >>> Rather than SUNW as a prefix why not "org.opensolaris." or "com.sun" ? >> >> I've no strong opinion about this ... >> do we have some internal structure for such names? >> >> "com.sun.inetd" seems too.... "broad" for my liking... >> "com.sun.solaris.inetd" might be a better/tighter fit. > > or even just "solaris.inetd" which matches the hierarchy used for RBAC > authorisations. That crossed my mind, but I wasn't sure if it would be desirable to have two name spaces that look the same but are for different purposes. Someone might assume that a project named "solaris.inetd" meant there was an RBAC authroisation or that if there was an RBAC authorisation called "solaris.inetd" that it referred to the same object as the project name. Good engineering would suggest that a project called "solaris.inetd" wasn't used for sendmail and simiarly that an RBAC authorisation bearing the same name also didn't refer to something that wasn't inetd... I don't mind updating the spec to say that names are "solaris.*" and that if there's already an RBAC name for that object then the project must bear the same name. Also if there isn't an exact match in the RBAC names that the name must otherwise fit into the RBAC naming heirarchy. Thus solaris.inetd would become "solaris.network.inetd". Darren From Darren.Reed@Sun.COM Wed Jun 3 07:48:20 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53EmKYU010736 for ; Wed, 3 Jun 2009 07:48:20 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n53EmKhm010756 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Jun 2009 08:48:20 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00I013SJFW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 07:48:19 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO00IAA3SI2S00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 07:48:19 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n53EmIZh006964 for ; Wed, 03 Jun 2009 14:48:18 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKO00L001NIY200@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:48:18 +0100 (BST) Received: from [129.157.18.122] ([unknown] [129.157.18.122]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKO00DD53S8N8B0@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:48:08 +0100 (BST) Date: Wed, 03 Jun 2009 16:48:04 +0200 From: Darren Reed Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A268A7C.7090802@Sun.COM> Sender: Darren.Reed@Sun.COM To: Menno.Lageman@Sun.COM Cc: PSARC-EXT Message-id: <4A268D24.1040509@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A268A7C.7090802@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 1011 Menno Lageman wrote: ... >> >> New Project >> ~~~~~~~~~~~ >> This case will deliver a new project called "SUNWinetd" that will >> be added to /etc/project. The line to be added is: >> >> SUNWinetd:5::::project.max-contracts=remove > > - How will this cope with multiple occurrences of a resource control > in the project database? Taking the example from project(4) > > beatles:100:The Beatles:john,paul,george,ringo::task.max-lwps= > (privileged,100,signal=SIGTERM),(privileged,110,deny); > process.max-file-descriptor > > what would happen if one specified SUNWinetd:5::::task.max-lwps=remove ? Any object in Solaris can only belong to one project. So a process either belongs to the "beatles" project or it belongs to the "SUNWinetd" project. > - You specifically mention /etc/project, so I assume a network based > project database isn't updated, right? That would be (re)built as part of the installation process. It is a similar problem to updating /etc/services, etc. Darren From Menno.Lageman@sun.com Wed Jun 3 08:04:19 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53F4JuA016855 for ; Wed, 3 Jun 2009 08:04:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n53F4EAQ010108 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Jun 2009 08:04:19 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00JCN4J6ZU00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 08:04:18 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO00HJZ4J58C90@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 08:04:17 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n53F4G3N028780 for ; Wed, 03 Jun 2009 15:04:16 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKO00I0049A4300@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 16:04:16 +0100 (BST) Received: from [129.159.237.204] ([unknown] [129.159.237.204]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKO00MXD4IR0EA0@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 16:04:03 +0100 (BST) Date: Wed, 03 Jun 2009 17:04:12 +0200 From: Menno Lageman Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A268D24.1040509@Sun.COM> Sender: Menno.Lageman@sun.com To: Darren Reed Cc: PSARC-EXT Reply-to: Menno.Lageman@sun.com Message-id: <4A2690EC.6090802@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A268A7C.7090802@Sun.COM> <4A268D24.1040509@Sun.COM> User-Agent: Thunderbird 2.0.0.14 (X11/20080531) Status: RO Content-Length: 1893 On 06/03/09 16:48, Darren Reed wrote: > Menno Lageman wrote: > ... >>> >>> New Project >>> ~~~~~~~~~~~ >>> This case will deliver a new project called "SUNWinetd" that will >>> be added to /etc/project. The line to be added is: >>> >>> SUNWinetd:5::::project.max-contracts=remove >> >> - How will this cope with multiple occurrences of a resource control >> in the project database? Taking the example from project(4) >> >> beatles:100:The Beatles:john,paul,george,ringo::task.max-lwps= >> (privileged,100,signal=SIGTERM),(privileged,110,deny); >> process.max-file-descriptor >> >> what would happen if one specified SUNWinetd:5::::task.max-lwps=remove ? > > Any object in Solaris can only belong to one project. > So a process either belongs to the "beatles" project or it belongs to > the "SUNWinetd" project. Sorry, I was too quick with copy/paste: the 'SUNWinetd' should have been 'beatles' of course. Let's try again: - How will this cope with multiple occurrences of a resource control in the project database? Taking the example from project(4) beatles:100:The Beatles:john,paul,george,ringo::task.max-lwps= (privileged,100,signal=SIGTERM),(privileged,110,deny); process.max-file-descriptor what would happen if one specified beatles:100::::task.max-lwps=remove ? Would this remove the 'privileged,100,signal=SIGTERM' occurance, the 'privileged,110,deny' occurrence, both occurrences, or none from /etc/project? > >> - You specifically mention /etc/project, so I assume a network based >> project database isn't updated, right? > > That would be (re)built as part of the installation process. > It is a similar problem to updating /etc/services, etc. I don't think the regular instalation process updates an external project database in NIS or LDAP. Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno From Darren.Reed@sun.com Wed Jun 3 08:15:53 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53FFrIj009503 for ; Wed, 3 Jun 2009 08:15:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n53FFpfd028649 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 3 Jun 2009 09:15:52 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00L0T52F2U00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 09:15:51 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO0091C52E36D0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 09:15:51 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n53FFogU010780 for ; Wed, 03 Jun 2009 15:15:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKO00L002LAF200@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 16:15:50 +0100 (BST) Received: from [129.157.18.122] ([unknown] [129.157.18.122]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKO00MFP51K9E90@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 16:15:20 +0100 (BST) Date: Wed, 03 Jun 2009 17:15:15 +0200 From: Darren Reed Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A2690EC.6090802@Sun.COM> Sender: Darren.Reed@sun.com To: Menno.Lageman@sun.com Cc: PSARC-EXT Message-id: <4A269383.5070602@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A268A7C.7090802@Sun.COM> <4A268D24.1040509@Sun.COM> <4A2690EC.6090802@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 2189 Menno Lageman wrote: > On 06/03/09 16:48, Darren Reed wrote: >> Menno Lageman wrote: >> ... >>>> >>>> New Project >>>> ~~~~~~~~~~~ >>>> This case will deliver a new project called "SUNWinetd" that will >>>> be added to /etc/project. The line to be added is: >>>> >>>> SUNWinetd:5::::project.max-contracts=remove >>> >>> - How will this cope with multiple occurrences of a resource control >>> in the project database? Taking the example from project(4) >>> >>> beatles:100:The Beatles:john,paul,george,ringo::task.max-lwps= >>> (privileged,100,signal=SIGTERM),(privileged,110,deny); >>> process.max-file-descriptor >>> >>> what would happen if one specified >>> SUNWinetd:5::::task.max-lwps=remove ? >> >> Any object in Solaris can only belong to one project. >> So a process either belongs to the "beatles" project or it belongs to >> the "SUNWinetd" project. > > Sorry, I was too quick with copy/paste: the 'SUNWinetd' should have > been 'beatles' of course. Let's try again: > > - How will this cope with multiple occurrences of a resource control > in the project database? Taking the example from project(4) > > beatles:100:The Beatles:john,paul,george,ringo::task.max-lwps= > (privileged,100,signal=SIGTERM),(privileged,110,deny); > process.max-file-descriptor > > what would happen if one specified beatles:100::::task.max-lwps=remove > ? Would this remove the 'privileged,100,signal=SIGTERM' occurance, the > 'privileged,110,deny' occurrence, both occurrences, or none from > /etc/project? This case proposes no changes to the behaviour of the system if there are multiple projects defined with the same name. For example, the same question might be asked of this scenario: beatles:100:The Beatles:john,paul,george,ringo::task.max-lwps= (privileged,100,signal=SIGTERM),(privileged,110,deny); process.max-file-descriptor beatles:100::::task.max-lwps=(privileged,1,signal=SIGINT) Given that the man page project(4) does not describe what happens when there are multiple lines present with the same project name, nor if it should or should not be done, the behaviour will remain as it is: undefined. Darren From Scott.Rotondo@sun.com Wed Jun 3 14:02:19 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n53L2I8L018238 for ; Wed, 3 Jun 2009 14:02:19 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n53L2FPI028545 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Jun 2009 05:02:18 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKO00H17L3TEG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 14:02:17 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKO00A8XL3SD870@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 14:02:17 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n53L2Gs1004964 for ; Wed, 03 Jun 2009 21:02:16 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKO00400IEV0G00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:02:16 -0600 (MDT) Received: from [129.146.108.62] ([unknown] [129.146.108.62]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKO00GJ6L3IXTG0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 03 Jun 2009 15:02:06 -0600 (MDT) Date: Wed, 03 Jun 2009 14:01:07 -0700 From: Scott Rotondo Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A268B01.8080905@Sun.COM> Sender: Scott.Rotondo@sun.com To: Darren Reed Cc: PSARC-EXT Message-id: <4A26E493.4090401@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 2188 Darren Reed wrote: > Darren J Moffat wrote: >> Darren Reed wrote: >>> Darren J Moffat wrote: >>>> Rather than SUNW as a prefix why not "org.opensolaris." or "com.sun" ? >>> >>> I've no strong opinion about this ... >>> do we have some internal structure for such names? >>> >>> "com.sun.inetd" seems too.... "broad" for my liking... >>> "com.sun.solaris.inetd" might be a better/tighter fit. >> >> or even just "solaris.inetd" which matches the hierarchy used for RBAC >> authorisations. > > That crossed my mind, but I wasn't sure if it would be desirable > to have two name spaces that look the same but are for different > purposes. Someone might assume that a project named "solaris.inetd" > meant there was an RBAC authroisation or that if there was an RBAC > authorisation called "solaris.inetd" that it referred to the same > object as the project name. Good engineering would suggest that a > project called "solaris.inetd" wasn't used for sendmail and simiarly > that an RBAC authorisation bearing the same name also didn't refer > to something that wasn't inetd... > > I don't mind updating the spec to say that names are "solaris.*" > and that if there's already an RBAC name for that object then the > project must bear the same name. Also if there isn't an exact match > in the RBAC names that the name must otherwise fit into the RBAC > naming heirarchy. Thus solaris.inetd would become > "solaris.network.inetd". > I agree that "solaris." is a good prefix for reserved project names. I don't think there necessarily needs to be a connection between the project name and any authorizations that might be used by software running under that project id. In particular, I recommend using the single "solaris." prefix in the same way that "SUNW" was suggested earlier and *not* trying to create hierarchical project names like "solaris.network.inetd". The latter usage at least suggests the existence of a higher-level solaris.network project that limits the resources of all the solaris.network.* projects. Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278) From Darren.Reed@sun.com Thu Jun 4 02:16:12 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n549GBtZ025469 for ; Thu, 4 Jun 2009 02:16:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n549G6hO022356 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Jun 2009 10:16:10 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKP00K1LJ2YQA00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 03:16:10 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKP00DIYJ2XLC40@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 03:16:09 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n549G8Zp010529 for ; Thu, 04 Jun 2009 09:16:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKP00A00HP7OD00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 10:16:08 +0100 (BST) Received: from [192.168.2.104] ([unknown] [88.100.101.51]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKP008UUJ2IID60@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 10:15:55 +0100 (BST) Date: Thu, 04 Jun 2009 11:15:48 +0200 From: Darren Reed Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A26E493.4090401@sun.com> Sender: Darren.Reed@sun.com To: Scott Rotondo Cc: PSARC-EXT Message-id: <4A2790C4.9040109@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> <4A26E493.4090401@sun.com> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 2688 In PSARC yesterday, Gary mentioned that he disliked the idea of having the names similar to those used for RBAC, lest it cause confusion. So that is 2 votes for "solaris.inetd" (you & Darren Moffat) and 1 against (Gary). So the only question that would remain is how should that name be classified and to my view, there's only one that makes sense: Project Private (it is an implementation detail of how the resource limit is being modified for inetd and not an architectural mechanism with which users/administrators are expected to with.) Darren Scott Rotondo wrote: > Darren Reed wrote: >> Darren J Moffat wrote: >>> Darren Reed wrote: >>>> Darren J Moffat wrote: >>>>> Rather than SUNW as a prefix why not "org.opensolaris." or >>>>> "com.sun" ? >>>> >>>> I've no strong opinion about this ... >>>> do we have some internal structure for such names? >>>> >>>> "com.sun.inetd" seems too.... "broad" for my liking... >>>> "com.sun.solaris.inetd" might be a better/tighter fit. >>> >>> or even just "solaris.inetd" which matches the hierarchy used for >>> RBAC authorisations. >> >> That crossed my mind, but I wasn't sure if it would be desirable >> to have two name spaces that look the same but are for different >> purposes. Someone might assume that a project named "solaris.inetd" >> meant there was an RBAC authroisation or that if there was an RBAC >> authorisation called "solaris.inetd" that it referred to the same >> object as the project name. Good engineering would suggest that a >> project called "solaris.inetd" wasn't used for sendmail and simiarly >> that an RBAC authorisation bearing the same name also didn't refer >> to something that wasn't inetd... >> >> I don't mind updating the spec to say that names are "solaris.*" >> and that if there's already an RBAC name for that object then the >> project must bear the same name. Also if there isn't an exact match >> in the RBAC names that the name must otherwise fit into the RBAC >> naming heirarchy. Thus solaris.inetd would become >> "solaris.network.inetd". >> > > I agree that "solaris." is a good prefix for reserved project names. I > don't think there necessarily needs to be a connection between the > project name and any authorizations that might be used by software > running under that project id. > > In particular, I recommend using the single "solaris." prefix in the > same way that "SUNW" was suggested earlier and *not* trying to create > hierarchical project names like "solaris.network.inetd". The latter > usage at least suggests the existence of a higher-level > solaris.network project that limits the resources of all the > solaris.network.* projects. > > Scott > From Darren.Moffat@sun.com Thu Jun 4 03:21:34 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n54ALX4j026337 for ; Thu, 4 Jun 2009 03:21:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n54ALJEk005452 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Jun 2009 18:21:32 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKP00005M3QOS00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 03:21:26 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKP00C7PM3PIIF0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 03:21:26 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n54ALPXW022755 for ; Thu, 04 Jun 2009 10:21:25 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKP00G00IJSAI00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 11:21:25 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKP00HZCM3CKL30@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 11:21:12 +0100 (BST) Date: Thu, 04 Jun 2009 11:21:12 +0100 From: Darren J Moffat Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A2790C4.9040109@Sun.COM> Sender: Darren.Moffat@sun.com To: Darren Reed Cc: Scott Rotondo , PSARC-EXT Message-id: <4A27A018.7000801@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> <4A26E493.4090401@sun.com> <4A2790C4.9040109@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 812 Darren Reed wrote: > In PSARC yesterday, Gary mentioned that he disliked the idea of having > the names similar to those used for RBAC, lest it cause confusion. Personally I don't think there will be confusion but it is a fair concern. > So that is 2 votes for "solaris.inetd" (you & Darren Moffat) and 1 > against (Gary). > > So the only question that would remain is how should that name be > classified and to my view, there's only one that makes sense: Project > Private (it is an implementation detail of how the resource limit is > being modified for inetd and not an architectural mechanism with which > users/administrators are expected to with.) Let me make yet another naming suggestion then.... We already have a "system" project why not: "system.inetd" "system.foo" -- Darren J Moffat From carlsonj@phorcys.east.sun.com Thu Jun 4 05:38:45 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n54CciOc026887 for ; Thu, 4 Jun 2009 05:38:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n54CcgF5002820 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Thu, 4 Jun 2009 06:38:44 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKP00J0XSGIOK00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 04 Jun 2009 05:38:42 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKP00JBUSGH2860@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 04 Jun 2009 05:38:42 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n54Cce2N061978; Thu, 04 Jun 2009 08:38:40 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n54CbVjf003031; Thu, 04 Jun 2009 08:37:31 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n54CbVcE003028; Thu, 04 Jun 2009 08:37:31 -0400 (EDT) Date: Thu, 04 Jun 2009 08:37:31 -0400 From: James Carlson Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A27A018.7000801@Sun.COM> To: Darren J Moffat Cc: Darren Reed , PSARC-EXT , Scott Rotondo Message-id: <18983.49163.269550.369629@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> <4A26E493.4090401@sun.com> <4A2790C4.9040109@Sun.COM> <4A27A018.7000801@Sun.COM> Status: RO Content-Length: 411 Darren J Moffat writes: > We already have a "system" project why not: > "system.inetd" > "system.foo" I think Scott's concern about nesting is valid, but that's otherwise a nice idea. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gww@sac.sfbay.sun.com Thu Jun 4 10:21:44 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n54HLhgE000862 for ; Thu, 4 Jun 2009 10:21:44 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n54HLZA6025424 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Jun 2009 01:21:43 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKQ001055K67R00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 10:21:42 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKQ00L3S5K6SD40@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 10:21:42 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n54HLeP4041208; Thu, 04 Jun 2009 10:21:40 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n54HLegQ000859; Thu, 04 Jun 2009 10:21:40 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n54HLeiT000858; Thu, 04 Jun 2009 10:21:40 -0700 (PDT) Date: Thu, 04 Jun 2009 10:21:40 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC/2009/332 New projects with boundless resources To: Darren.Moffat@sun.com, james.d.carlson@sun.com Cc: Darren.Reed@sun.com, PSARC-ext@sun.com, Scott.Rotondo@sun.com Message-id: <200906041721.n54HLeiT000858@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 280 > > We already have a "system" project why not: > > "system.inetd" > > "system.foo" > > I think Scott's concern about nesting is valid, but that's otherwise a > nice idea. Just as we have user.root, and group.staff, system.inetd seems the right level of nestedness. Gary.. From Scott.Rotondo@sun.com Thu Jun 4 10:22:50 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n54HMolH000894 for ; Thu, 4 Jun 2009 10:22:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n54HMgTo029845 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Jun 2009 10:22:49 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKQ00M115LZL100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 04 Jun 2009 11:22:48 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKQ008X75LZ3AC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 04 Jun 2009 11:22:47 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n54HMlbo019721 for ; Thu, 04 Jun 2009 17:22:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKQ009003VGDY00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 04 Jun 2009 11:22:47 -0600 (MDT) Received: from [129.146.108.62] ([unknown] [129.146.108.62]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKQ004WI5LHHA20@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 04 Jun 2009 11:22:30 -0600 (MDT) Date: Thu, 04 Jun 2009 10:21:31 -0700 From: Scott Rotondo Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <18983.49163.269550.369629@gargle.gargle.HOWL> Sender: Scott.Rotondo@sun.com To: James Carlson Cc: Darren J Moffat , Darren Reed , PSARC-EXT Message-id: <4A28029B.3020009@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> <4A26E493.4090401@sun.com> <4A2790C4.9040109@Sun.COM> <4A27A018.7000801@Sun.COM> <18983.49163.269550.369629@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 695 James Carlson wrote: > Darren J Moffat writes: >> We already have a "system" project why not: >> "system.inetd" >> "system.foo" > > I think Scott's concern about nesting is valid, but that's otherwise a > nice idea. > I have another suggestion. Seeing that /etc/project already uses user. and group., why not svc., where is derived from the service FMRI? That seems sufficient to achieve our real purpose, which is creating unambiguous names rather than reserving a Sun- or Solaris-controlled namespace. Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278) From carlsonj@phorcys.east.sun.com Thu Jun 4 10:31:54 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n54HVsIo001144 for ; Thu, 4 Jun 2009 10:31:54 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n54HVqdE007580 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@Sun.COM>; Thu, 4 Jun 2009 10:31:54 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKQ00003615C100@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 04 Jun 2009 11:31:53 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKQ008296143CF0@brm-avmta-1.central.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Thu, 04 Jun 2009 11:31:53 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n54HVpMF004923; Thu, 04 Jun 2009 13:31:51 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n54HUhLE004750; Thu, 04 Jun 2009 13:30:43 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n54HUh9S004747; Thu, 04 Jun 2009 13:30:43 -0400 (EDT) Date: Thu, 04 Jun 2009 13:30:43 -0400 From: James Carlson Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A28029B.3020009@sun.com> To: Scott Rotondo Cc: Darren J Moffat , Darren Reed , PSARC-EXT Message-id: <18984.1219.177193.456069@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> <4A26E493.4090401@sun.com> <4A2790C4.9040109@Sun.COM> <4A27A018.7000801@Sun.COM> <18983.49163.269550.369629@gargle.gargle.HOWL> <4A28029B.3020009@sun.com> Status: RO Content-Length: 832 Scott Rotondo writes: > James Carlson wrote: > > Darren J Moffat writes: > >> We already have a "system" project why not: > >> "system.inetd" > >> "system.foo" > > > > I think Scott's concern about nesting is valid, but that's otherwise a > > nice idea. > > > > I have another suggestion. Seeing that /etc/project already uses > user. and group., why not svc., where is > derived from the service FMRI? That seems sufficient to achieve our real > purpose, which is creating unambiguous names rather than reserving a > Sun- or Solaris-controlled namespace. Doubleplus good. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gww@sac.sfbay.sun.com Thu Jun 4 10:35:36 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n54HZZM5001276 for ; Thu, 4 Jun 2009 10:35:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n54HZVIc028502 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Jun 2009 18:35:35 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKQ00303679H500@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 10:35:33 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKQ00HK7678SW40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 10:35:32 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n54HZUp8060288; Thu, 04 Jun 2009 10:35:30 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n54HZUPO001273; Thu, 04 Jun 2009 10:35:30 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n54HZUJY001272; Thu, 04 Jun 2009 10:35:30 -0700 (PDT) Date: Thu, 04 Jun 2009 10:35:30 -0700 (PDT) From: Gary Winiger Subject: Re: PSARC/2009/332 New projects with boundless resources To: Scott.Rotondo@sun.com, james.d.carlson@sun.com Cc: Darren.Moffat@sun.com, Darren.Reed@sun.com, PSARC-ext@sun.com Message-id: <200906041735.n54HZUJY001272@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 253 > > I have another suggestion. Seeing that /etc/project already uses > > user. and group., why not svc., where is > > derived from the service FMRI? That seems sufficient to achieve our real > Doubleplus good. ;-) Gary.. From Darren.Moffat@sun.com Thu Jun 4 11:40:04 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n54Ie3mc003842 for ; Thu, 4 Jun 2009 11:40:03 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n54Idoi0010537 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 4 Jun 2009 19:40:02 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKQ0070B96N2I00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 12:39:59 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKQ002CT96MM740@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 12:39:59 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n54IdwEp028610 for ; Thu, 04 Jun 2009 18:39:58 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKQ00M0096KAD00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 19:39:58 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKQ00JKK96L6TA0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 04 Jun 2009 19:39:58 +0100 (BST) Date: Thu, 04 Jun 2009 19:39:57 +0100 From: Darren J Moffat Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <18984.1219.177193.456069@gargle.gargle.HOWL> Sender: Darren.Moffat@sun.com To: James Carlson Cc: Scott Rotondo , Darren Reed , PSARC-EXT Message-id: <4A2814FD.4040405@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> <4A26E493.4090401@sun.com> <4A2790C4.9040109@Sun.COM> <4A27A018.7000801@Sun.COM> <18983.49163.269550.369629@gargle.gargle.HOWL> <4A28029B.3020009@sun.com> <18984.1219.177193.456069@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 919 James Carlson wrote: > Scott Rotondo writes: >> James Carlson wrote: >>> Darren J Moffat writes: >>>> We already have a "system" project why not: >>>> "system.inetd" >>>> "system.foo" >>> I think Scott's concern about nesting is valid, but that's otherwise a >>> nice idea. >>> >> I have another suggestion. Seeing that /etc/project already uses >> user. and group., why not svc., where is >> derived from the service FMRI? That seems sufficient to achieve our real >> purpose, which is creating unambiguous names rather than reserving a >> Sun- or Solaris-controlled namespace. > > Doubleplus good. Like the use of svc as well when this is for a service, for other cases that aren't services (do we have any of those still ?) I'd be equally happy if system were used, but I'd prefer just one prefix (svc) be used unless there was a compelling reason otherwise. -- Darren J Moffat From Darren.Reed@sun.com Fri Jun 5 06:03:05 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n55D35dY010676 for ; Fri, 5 Jun 2009 06:03:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n55D32EZ009293 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Jun 2009 06:03:05 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKR00911O93J500@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Jun 2009 07:03:03 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKR00AQBO92QMC0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Jun 2009 07:03:02 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n55D31tH027111 for ; Fri, 05 Jun 2009 13:03:01 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKR00600N20BI00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Jun 2009 14:03:01 +0100 (BST) Received: from [129.157.18.122] ([unknown] [129.157.18.122]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKR00G7LO916NG0@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Jun 2009 14:03:01 +0100 (BST) Date: Fri, 05 Jun 2009 15:02:53 +0200 From: Darren Reed Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A2814FD.4040405@Sun.COM> Sender: Darren.Reed@sun.com To: Darren J Moffat Cc: James Carlson , Scott Rotondo , PSARC-EXT Message-id: <4A29177D.5020207@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> <4A26E493.4090401@sun.com> <4A2790C4.9040109@Sun.COM> <4A27A018.7000801@Sun.COM> <18983.49163.269550.369629@gargle.gargle.HOWL> <4A28029B.3020009@sun.com> <18984.1219.177193.456069@gargle.gargle.HOWL> <4A2814FD.4040405@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 3182 Updated spec below. Darren This project seeks micro/patch binding. Problem ======= The /etc/project file has been delivered (PSARC/1999/119) but its delivery did not define how we would add and name new projects, only that the numbers less than 100 were reserved. In addition, it did not offer full support of the features found in the project utilities such as prctl(1). Namespace ========= Now that the file has been shipped for a number of years, we need to make reasonable guesses about what customers may have done since its delivery. One such guess is that they may have created projects with names similar or the same as SMF FMRIs or executables with which they are associated. Thus in creating a new project to be shipped by default, using a name such as "login" or "init" or "inetd" cannot be considered to be without risk. To provide us with the required flexibility for future enginering, this case proposes that all project names starting with "SUNW" be reserved and that they are not to be used by customers to define their own projects. This limitation needs to be documented in updates to project(4) and projadd(1M). Removing Limits =============== Using prctl(1), it is possible (depending on your privileges) to add, change or remove resource limits associated with projects. When using projadd(1M), it is only possible to define projects in terms of new limits they will have: it is not possible to remove an inherited resource limit using a project definition in /etc/project. Thus this case would like to propose that the /etc/project file be extended to allow resource limits to be removed. The suggested syntax is to simply be '=removed'. As an example, it would be possible to use "project.max-contracts=removed". Implementation ============== This cases proposes to implement the above suggestions and to deliver the following changes to the existing platform. New Project ~~~~~~~~~~~ | This case will deliver a new project called "svc.inetd" that will be added to /etc/project. The line to be added is: | svc.inetd:5::::project.max-contracts=remove | The project name "svc.inetd" is a Project Private interface. svc:/network/inetd:default ~~~~~~~~~~~~~~~~~~~~~~~~~~ The manifest for svc:/network/inetd:default will be updated to define | the default inetd SMF service as a member of the svc.inetd project. Discussion ========== It is reasonable to ask the question if one daemon has a resource control problem, isn't it likely others will and thus isn't the inetd problem being solved more generic? To answer that question, it behooves us to recognise that inetd is a rather special daemon and in SMF parlance, it is also in a special cateogry - "restarter". The problem being investigated here (6271923) is particular to inetd in specific workload testing. Whilst we shouldn't be engineering the system to require tuning, removing limits for all processes removes the protection the limits offer, see PSARC/2004/460. In this regard, the best course of action is for project teams to analyse and understand the execution profiles that their daemons are likely to have and deliver special project defintions as required. From gdamore@sun.com Fri Jun 5 07:55:56 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n55EttAI012212 for ; Fri, 5 Jun 2009 07:55:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n55Etq9D009278 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Jun 2009 15:55:55 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKR00K05TH6HA00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 05 Jun 2009 07:55:54 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKR00FMNTH62B30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 05 Jun 2009 07:55:54 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n55Etsmv019885 for ; Fri, 05 Jun 2009 07:55:54 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKR00D00TBCX500@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 05 Jun 2009 07:55:54 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKR00CAGTH5EUF0@fe-sfbay-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 05 Jun 2009 07:55:54 -0700 (PDT) Date: Fri, 05 Jun 2009 07:55:53 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A29177D.5020207@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren Reed Cc: Darren J Moffat , James Carlson , Scott Rotondo , PSARC-EXT Message-id: <4A2931F9.2040505@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> <4A26E493.4090401@sun.com> <4A2790C4.9040109@Sun.COM> <4A27A018.7000801@Sun.COM> <18983.49163.269550.369629@gargle.gargle.HOWL> <4A28029B.3020009@sun.com> <18984.1219.177193.456069@gargle.gargle.HOWL> <4A2814FD.4040405@Sun.COM> <4A29177D.5020207@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3347 +1 Darren Reed wrote: > Updated spec below. > > Darren > > This project seeks micro/patch binding. > > Problem > ======= > The /etc/project file has been delivered (PSARC/1999/119) but its > delivery did not define how we would add and name new projects, > only that the numbers less than 100 were reserved. In addition, > it did not offer full support of the features found in the project > utilities such as prctl(1). > > Namespace > ========= > Now that the file has been shipped for a number of years, we need > to make reasonable guesses about what customers may have done since > its delivery. One such guess is that they may have created projects > with names similar or the same as SMF FMRIs or executables with which > they are associated. Thus in creating a new project to be shipped by > default, using a name such as "login" or "init" or "inetd" cannot be > considered to be without risk. > > To provide us with the required flexibility for future enginering, > this case proposes that all project names starting with "SUNW" be > reserved and that they are not to be used by customers to define > their own projects. This limitation needs to be documented in > updates to project(4) and projadd(1M). > > Removing Limits > =============== > Using prctl(1), it is possible (depending on your privileges) to > add, change or remove resource limits associated with projects. > When using projadd(1M), it is only possible to define projects in > terms of new limits they will have: it is not possible to remove > an inherited resource limit using a project definition in > /etc/project. > > Thus this case would like to propose that the /etc/project file > be extended to allow resource limits to be removed. The suggested > syntax is to simply be '=removed'. As an example, > it would be possible to use "project.max-contracts=removed". > > Implementation > ============== > This cases proposes to implement the above suggestions and to > deliver the following changes to the existing platform. > > New Project > ~~~~~~~~~~~ > | This case will deliver a new project called "svc.inetd" that will > be added to /etc/project. The line to be added is: > > | svc.inetd:5::::project.max-contracts=remove > > | The project name "svc.inetd" is a Project Private interface. > > svc:/network/inetd:default > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > The manifest for svc:/network/inetd:default will be updated to define > | the default inetd SMF service as a member of the svc.inetd project. > > Discussion > ========== > It is reasonable to ask the question if one daemon has a resource > control problem, isn't it likely others will and thus isn't the > inetd problem being solved more generic? To answer that question, > it behooves us to recognise that inetd is a rather special daemon > and in SMF parlance, it is also in a special cateogry - "restarter". > > The problem being investigated here (6271923) is particular to inetd > in specific workload testing. Whilst we shouldn't be engineering the > system to require tuning, removing limits for all processes removes > the protection the limits offer, see PSARC/2004/460. In this regard, > the best course of action is for project teams to analyse and > understand the execution profiles that their daemons are likely to > have and deliver special project defintions as required. > From MAILER-DAEMON Fri Jun 5 14:23:15 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n55LNEf8021024 for ; Fri, 5 Jun 2009 14:23:14 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n55LN8kl026505; Fri, 5 Jun 2009 22:23:09 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKS00F01BEL0900@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Jun 2009 14:23:09 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKS00CV3BEKJU20@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Jun 2009 14:23:08 -0700 (PDT) Received: from steve1 (steve1.SFBay.Sun.COM [129.146.224.51]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n55LN82t242688; Fri, 05 Jun 2009 14:23:08 -0700 (PDT) Date: Fri, 05 Jun 2009 14:23:04 -0700 From: Steve Lawrence Subject: Re: PSARC/2009/332 New projects with boundless resources To: Darren.Reed@sun.com, Darren.Moffat@sun.com, James.D.Carlson@sun.com, Scott.Rotondo@sun.com, PSARC-ext@sun.com Message-id: <20090605212303.GF3482@steve1.eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 User-Agent: Mutt/1.5.17 (2007-11-01) Status: RO Content-Length: 776 > Removing Limits > =============== > Using prctl(1), it is possible (depending on your privileges) to > add, change or remove resource limits associated with projects. > When using projadd(1M), it is only possible to define projects in > terms of new limits they will have: it is not possible to remove > an inherited resource limit using a project definition in > /etc/project. > > Thus this case would like to propose that the /etc/project file > be extended to allow resource limits to be removed. The suggested > syntax is to simply be '=removed'. As an example, > it would be possible to use "project.max-contracts=removed". I assume we would maintain the current removal behavor, which is done by specifying the rctl name without any value? -Steve L. From Darren.Reed@Sun.COM Fri Jun 5 15:38:02 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n55Mc1WI022864 for ; Fri, 5 Jun 2009 15:38:02 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n55MbxUh006265 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Jun 2009 23:38:01 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKS00B01EVCT300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 05 Jun 2009 15:38:00 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKS00LBOEVB0460@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 05 Jun 2009 15:38:00 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n55MbxcX029659 for ; Fri, 05 Jun 2009 22:37:59 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKS00H00ENEMS00@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 05 Jun 2009 23:37:59 +0100 (BST) Received: from [192.168.2.104] ([unknown] [88.100.101.51]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKS00B8WEVANSC0@fe-emea-09.sun.com>; Fri, 05 Jun 2009 23:37:59 +0100 (BST) Date: Sat, 06 Jun 2009 00:37:50 +0200 From: Darren Reed Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <20090605212303.GF3482@steve1.eng.sun.com> Sender: Darren.Reed@Sun.COM To: Steve Lawrence Cc: Darren.Moffat@Sun.COM, James.D.Carlson@Sun.COM, Scott.Rotondo@Sun.COM, PSARC-ext@Sun.COM Message-id: <4A299E3E.1080102@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20090605212303.GF3482@steve1.eng.sun.com> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 928 Steve Lawrence wrote: >> Removing Limits >> =============== >> Using prctl(1), it is possible (depending on your privileges) to >> add, change or remove resource limits associated with projects. >> When using projadd(1M), it is only possible to define projects in >> terms of new limits they will have: it is not possible to remove >> an inherited resource limit using a project definition in >> /etc/project. >> >> Thus this case would like to propose that the /etc/project file >> be extended to allow resource limits to be removed. The suggested >> syntax is to simply be '=removed'. As an example, >> it would be possible to use "project.max-contracts=removed". >> > > I assume we would maintain the current removal behavor, which is done > by specifying the rctl name without any value? > Yes. The current behaviour is being maintained and the above enhancement provided to compliment it. Darren From Scott.Rotondo@sun.com Fri Jun 5 15:45:42 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n55MjguG023046 for ; Fri, 5 Jun 2009 15:45:42 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n55MjceA043395 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 5 Jun 2009 16:45:42 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKS00K0DF85QQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Jun 2009 15:45:41 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKS00C13F85JY80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Jun 2009 15:45:41 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n55MjeMZ013127 for ; Fri, 05 Jun 2009 22:45:41 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKS00100EGEWF00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Jun 2009 16:45:40 -0600 (MDT) Received: from viaggio.local ([unknown] [10.7.251.213]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKS00GO4F81CFD0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 05 Jun 2009 16:45:38 -0600 (MDT) Date: Fri, 05 Jun 2009 15:45:37 -0700 From: Scott Rotondo Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A29177D.5020207@Sun.COM> Sender: Scott.Rotondo@sun.com To: Darren Reed Cc: Darren J Moffat , James Carlson , PSARC-EXT Message-id: <4A29A011.2070900@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> <4A26E493.4090401@sun.com> <4A2790C4.9040109@Sun.COM> <4A27A018.7000801@Sun.COM> <18983.49163.269550.369629@gargle.gargle.HOWL> <4A28029B.3020009@sun.com> <18984.1219.177193.456069@gargle.gargle.HOWL> <4A2814FD.4040405@Sun.COM> <4A29177D.5020207@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) Status: RO Content-Length: 3603 Darren Reed wrote: > Updated spec below. > > Darren > > This project seeks micro/patch binding. > > Problem > ======= > The /etc/project file has been delivered (PSARC/1999/119) but its > delivery did not define how we would add and name new projects, > only that the numbers less than 100 were reserved. In addition, > it did not offer full support of the features found in the project > utilities such as prctl(1). > > Namespace > ========= > Now that the file has been shipped for a number of years, we need > to make reasonable guesses about what customers may have done since > its delivery. One such guess is that they may have created projects > with names similar or the same as SMF FMRIs or executables with which > they are associated. Thus in creating a new project to be shipped by > default, using a name such as "login" or "init" or "inetd" cannot be > considered to be without risk. > > To provide us with the required flexibility for future enginering, > this case proposes that all project names starting with "SUNW" be > reserved and that they are not to be used by customers to define > their own projects. This limitation needs to be documented in > updates to project(4) and projadd(1M). Don't you want to update this paragraph to reserve the svc. namespace instead? Scott > > Removing Limits > =============== > Using prctl(1), it is possible (depending on your privileges) to > add, change or remove resource limits associated with projects. > When using projadd(1M), it is only possible to define projects in > terms of new limits they will have: it is not possible to remove > an inherited resource limit using a project definition in > /etc/project. > > Thus this case would like to propose that the /etc/project file > be extended to allow resource limits to be removed. The suggested > syntax is to simply be '=removed'. As an example, > it would be possible to use "project.max-contracts=removed". > > Implementation > ============== > This cases proposes to implement the above suggestions and to > deliver the following changes to the existing platform. > > New Project > ~~~~~~~~~~~ > | This case will deliver a new project called "svc.inetd" that will > be added to /etc/project. The line to be added is: > > | svc.inetd:5::::project.max-contracts=remove > > | The project name "svc.inetd" is a Project Private interface. > > svc:/network/inetd:default > ~~~~~~~~~~~~~~~~~~~~~~~~~~ > The manifest for svc:/network/inetd:default will be updated to define > | the default inetd SMF service as a member of the svc.inetd project. > > Discussion > ========== > It is reasonable to ask the question if one daemon has a resource > control problem, isn't it likely others will and thus isn't the > inetd problem being solved more generic? To answer that question, > it behooves us to recognise that inetd is a rather special daemon > and in SMF parlance, it is also in a special cateogry - "restarter". > > The problem being investigated here (6271923) is particular to inetd > in specific workload testing. Whilst we shouldn't be engineering the > system to require tuning, removing limits for all processes removes > the protection the limits offer, see PSARC/2004/460. In this regard, > the best course of action is for project teams to analyse and > understand the execution profiles that their daemons are likely to > have and deliver special project defintions as required. > -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278) From Darren.Reed@sun.com Fri Jun 5 16:00:51 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n55N0oL8000395 for ; Fri, 5 Jun 2009 16:00:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n55N0eFr021824 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 6 Jun 2009 07:00:49 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKS00109FXAXF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 05 Jun 2009 17:00:46 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKS00E4YFX9T340@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 05 Jun 2009 17:00:46 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n55N0j0m011388 for ; Fri, 05 Jun 2009 23:00:45 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKS00300FX2YX00@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 06 Jun 2009 00:00:45 +0100 (BST) Received: from [192.168.2.104] ([unknown] [88.100.101.51]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKS002W3FX84C00@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 06 Jun 2009 00:00:45 +0100 (BST) Date: Sat, 06 Jun 2009 01:00:36 +0200 From: Darren Reed Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A29A011.2070900@sun.com> Sender: Darren.Reed@sun.com To: Scott Rotondo Cc: Darren J Moffat , James Carlson , PSARC-EXT Message-id: <4A29A394.7010700@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> <4A26E493.4090401@sun.com> <4A2790C4.9040109@Sun.COM> <4A27A018.7000801@Sun.COM> <18983.49163.269550.369629@gargle.gargle.HOWL> <4A28029B.3020009@sun.com> <18984.1219.177193.456069@gargle.gargle.HOWL> <4A2814FD.4040405@Sun.COM> <4A29177D.5020207@Sun.COM> <4A29A011.2070900@sun.com> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 1398 Scott Rotondo wrote: > Darren Reed wrote: >> Updated spec below. >> >> Darren >> >> This project seeks micro/patch binding. >> >> Problem >> ======= >> The /etc/project file has been delivered (PSARC/1999/119) but its >> delivery did not define how we would add and name new projects, >> only that the numbers less than 100 were reserved. In addition, >> it did not offer full support of the features found in the project >> utilities such as prctl(1). >> >> Namespace >> ========= >> Now that the file has been shipped for a number of years, we need >> to make reasonable guesses about what customers may have done since >> its delivery. One such guess is that they may have created projects >> with names similar or the same as SMF FMRIs or executables with which >> they are associated. Thus in creating a new project to be shipped by >> default, using a name such as "login" or "init" or "inetd" cannot be >> considered to be without risk. >> >> To provide us with the required flexibility for future enginering, >> this case proposes that all project names starting with "SUNW" be >> reserved and that they are not to be used by customers to define >> their own projects. This limitation needs to be documented in >> updates to project(4) and projadd(1M). > > Don't you want to update this paragraph to reserve the svc. > namespace instead? Yes, my apologies. Missed that! Darren From MAILER-DAEMON Mon Jun 8 18:25:56 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n591PtPe026329 for ; Mon, 8 Jun 2009 18:25:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n591PjEw005885; Tue, 9 Jun 2009 09:25:54 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKY00B0L6N5ZM00@nwk-avmta-2.sfbay.sun.com>; Mon, 08 Jun 2009 18:25:53 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKY001C96N5K370@nwk-avmta-2.sfbay.sun.com>; Mon, 08 Jun 2009 18:25:53 -0700 (PDT) Received: from rosseau (rosseau.SFBay.Sun.COM [129.146.228.252]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n591PqDs638869; Mon, 08 Jun 2009 18:25:52 -0700 (PDT) Date: Mon, 08 Jun 2009 18:26:33 -0700 From: Stephen Hahn Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A26825C.9000807@Sun.COM> To: Darren Reed Cc: PSARC-EXT Message-id: <20090609012633.GB28739@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 1538 * Darren Reed [2009-06-03 14:04]: > Namespace > ========= > Now that the file has been shipped for a number of years, we need > to make reasonable guesses about what customers may have done since > its delivery. One such guess is that they may have created projects > with names similar or the same as SMF FMRIs or executables with which > they are associated. Thus in creating a new project to be shipped by > default, using a name such as "login" or "init" or "inetd" cannot be > considered to be without risk. Although it seems to have been slightly mangled in the translation to a product manpage in project(4): projname The name of the project. The name must be a string that consists of alphanumeric charac- ters, underline (_) characters, hyphens (-), and periods (.). The period, which is reserved for projects with special meaning to the operating system, can be used only in the names of default projects for users. projname cannot contain colons (:) or newline charac- ters. you, as an operating system designer, are allowed to use '.' to provide an escape from the otherwise flat namespace. I would probably avoid the stock symbol prefix, and merely use "svc.inetd", etc. (The mangling is the "used only" case, which is a statement that there are only a few known reserved patterns at present.) - Stephen From MAILER-DAEMON Mon Jun 8 18:29:04 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n591T4SO026343 for ; Mon, 8 Jun 2009 18:29:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n591T2wk010870; Mon, 8 Jun 2009 18:29:02 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKY00K076SDA300@nwk-avmta-1.sfbay.Sun.COM>; Mon, 08 Jun 2009 18:29:01 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKY00G8U6SDDX10@nwk-avmta-1.sfbay.Sun.COM>; Mon, 08 Jun 2009 18:29:01 -0700 (PDT) Received: from rosseau (rosseau.SFBay.Sun.COM [129.146.228.252]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n591T0ZG639107; Mon, 08 Jun 2009 18:29:00 -0700 (PDT) Date: Mon, 08 Jun 2009 18:29:41 -0700 From: Stephen Hahn Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A26825C.9000807@Sun.COM> To: Darren Reed Cc: PSARC-EXT Message-id: <20090609012941.GC28739@eng.sun.com> Organization: Solaris Kernel Development; Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 494 * Darren Reed [2009-06-03 14:04]: > New Project > ~~~~~~~~~~~ > This case will deliver a new project called "SUNWinetd" that will > be added to /etc/project. The line to be added is: > > SUNWinetd:5::::project.max-contracts=remove I presume this is from the privileged control of 10 000 contracts that init(1M) starts out with? Is there a bug ID which has some discussion about someone hitting this value (but not, say, project.max-port-ids)? Thanks Stephen From Darren.Reed@sun.com Mon Jun 8 23:23:49 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n596Nmd4028476 for ; Mon, 8 Jun 2009 23:23:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n596NjbT028779 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 9 Jun 2009 14:23:47 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKY00213KFKV100@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 09 Jun 2009 00:23:44 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKY00HFKKFJHU50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 09 Jun 2009 00:23:44 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n596NhEC028103 for ; Tue, 09 Jun 2009 06:23:43 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKY00800KE6OX00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 09 Jun 2009 07:23:43 +0100 (BST) Received: from [192.168.2.100] ([unknown] [88.100.101.51]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKY00MPWKFITM30@fe-emea-10.sun.com>; Tue, 09 Jun 2009 07:23:42 +0100 (BST) Date: Tue, 09 Jun 2009 08:23:28 +0200 From: Darren Reed Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <20090609012941.GC28739@eng.sun.com> Sender: Darren.Reed@sun.com To: Stephen Hahn Cc: PSARC-EXT Message-id: <4A2DFFE0.6030506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <20090609012941.GC28739@eng.sun.com> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 719 Stephen Hahn wrote: > * Darren Reed [2009-06-03 14:04]: > >> New Project >> ~~~~~~~~~~~ >> This case will deliver a new project called "SUNWinetd" that will >> be added to /etc/project. The line to be added is: >> >> SUNWinetd:5::::project.max-contracts=remove >> > > I presume this is from the privileged control of 10 000 contracts that > init(1M) starts out with? Is there a bug ID which has some discussion > about someone hitting this value (but not, say, project.max-port-ids)? > It was mentioned further down in the text submitted: Discussion ========== ... The problem being investigated here (6271923) is particular to inetd in specific workload testing. ... Darren From Darren.Reed@sun.com Wed Jun 17 03:42:04 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5HAg4aB003704 for ; Wed, 17 Jun 2009 03:42:04 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5HAfplN026621 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Jun 2009 11:42:03 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLD00205PQ1HS00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Jun 2009 03:42:01 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLD00G44PQ0DGA0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 17 Jun 2009 03:42:01 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5HAg0BD021281 for ; Wed, 17 Jun 2009 10:42:00 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLD00200PCQV300@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 17 Jun 2009 11:42:00 +0100 (BST) Received: from [129.157.18.162] ([unknown] [129.157.18.162]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLD00LODPPWWO50@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 17 Jun 2009 11:41:57 +0100 (BST) Date: Wed, 17 Jun 2009 12:41:28 +0200 From: Darren Reed Subject: Re: PSARC/2009/332 New projects with boundless resources In-reply-to: <4A2931F9.2040505@sun.com> Sender: Darren.Reed@sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , James Carlson , Scott Rotondo , PSARC-EXT Message-id: <4A38C858.1020307@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A26825C.9000807@Sun.COM> <4A2684EB.1070506@Sun.COM> <4A2686F0.6070109@Sun.COM> <4A26876B.7000907@Sun.COM> <4A268B01.8080905@Sun.COM> <4A26E493.4090401@sun.com> <4A2790C4.9040109@Sun.COM> <4A27A018.7000801@Sun.COM> <18983.49163.269550.369629@gargle.gargle.HOWL> <4A28029B.3020009@sun.com> <18984.1219.177193.456069@gargle.gargle.HOWL> <4A2814FD.4040405@Sun.COM> <4A29177D.5020207@Sun.COM> <4A2931F9.2040505@sun.com> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 3557 With this., the timeout, and all apparent issues resolved, I'm marking this case closed, approved. Garrett D'Amore wrote: > +1 > > Darren Reed wrote: >> Updated spec below. >> >> Darren >> >> This project seeks micro/patch binding. >> >> Problem >> ======= >> The /etc/project file has been delivered (PSARC/1999/119) but its >> delivery did not define how we would add and name new projects, >> only that the numbers less than 100 were reserved. In addition, >> it did not offer full support of the features found in the project >> utilities such as prctl(1). >> >> Namespace >> ========= >> Now that the file has been shipped for a number of years, we need >> to make reasonable guesses about what customers may have done since >> its delivery. One such guess is that they may have created projects >> with names similar or the same as SMF FMRIs or executables with which >> they are associated. Thus in creating a new project to be shipped by >> default, using a name such as "login" or "init" or "inetd" cannot be >> considered to be without risk. >> >> To provide us with the required flexibility for future enginering, >> this case proposes that all project names starting with "SUNW" be >> reserved and that they are not to be used by customers to define >> their own projects. This limitation needs to be documented in >> updates to project(4) and projadd(1M). >> >> Removing Limits >> =============== >> Using prctl(1), it is possible (depending on your privileges) to >> add, change or remove resource limits associated with projects. >> When using projadd(1M), it is only possible to define projects in >> terms of new limits they will have: it is not possible to remove >> an inherited resource limit using a project definition in >> /etc/project. >> >> Thus this case would like to propose that the /etc/project file >> be extended to allow resource limits to be removed. The suggested >> syntax is to simply be '=removed'. As an example, >> it would be possible to use "project.max-contracts=removed". >> >> Implementation >> ============== >> This cases proposes to implement the above suggestions and to >> deliver the following changes to the existing platform. >> >> New Project >> ~~~~~~~~~~~ >> | This case will deliver a new project called "svc.inetd" that will >> be added to /etc/project. The line to be added is: >> >> | svc.inetd:5::::project.max-contracts=remove >> >> | The project name "svc.inetd" is a Project Private interface. >> >> svc:/network/inetd:default >> ~~~~~~~~~~~~~~~~~~~~~~~~~~ >> The manifest for svc:/network/inetd:default will be updated to define >> | the default inetd SMF service as a member of the svc.inetd project. >> >> Discussion >> ========== >> It is reasonable to ask the question if one daemon has a resource >> control problem, isn't it likely others will and thus isn't the >> inetd problem being solved more generic? To answer that question, >> it behooves us to recognise that inetd is a rather special daemon >> and in SMF parlance, it is also in a special cateogry - "restarter". >> >> The problem being investigated here (6271923) is particular to inetd >> in specific workload testing. Whilst we shouldn't be engineering the >> system to require tuning, removing limits for all processes removes >> the protection the limits offer, see PSARC/2004/460. In this regard, >> the best course of action is for project teams to analyse and >> understand the execution profiles that their daemons are likely to >> have and deliver special project defintions as required. >> >