From gww@sac.sfbay.sun.com Thu Feb 7 14:30:25 2008 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 m17MUPad015450 for ; Thu, 7 Feb 2008 14:30:25 -0800 (PST) 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 m17MUMIn049231; Thu, 7 Feb 2008 15:30:24 -0700 (MST) 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 <0JVW0001R3UN7T00@brm-avmta-1.central.sun.com>; Thu, 07 Feb 2008 15:30:23 -0700 (MST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVW00LX83ULHR10@brm-avmta-1.central.sun.com>; Thu, 07 Feb 2008 15:30:21 -0700 (MST) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17MUJrS065454; Thu, 07 Feb 2008 14:30:19 -0800 (PST) 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 m17MMmjE015389; Thu, 07 Feb 2008 14:22:48 -0800 (PST) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m17MMmTw015385; Thu, 07 Feb 2008 14:22:48 -0800 (PST) Date: Thu, 07 Feb 2008 14:22:48 -0800 (PST) From: Gary Winiger Subject: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] To: PSARC-ext@sun.com Cc: Menno.Lageman@sun.com Message-id: <200802072222.m17MMmTw015385@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 8271 I'm sponsoring this fast track for Menno Lageman. This project proposes to convert the current mechanism for configuring the extended accounting facility in Solaris to use SMF and to fix some long standing problems with extended accounting. It requests a Patch release binding in case there's a need to back port. The interface stabilities are noted in the proposal. With the conversion to SMF both the Project Private /etc/acctadm.conf file and the acctadm -u option to read in that file are removed. Upon upgrade /etc/acctadm.conf contents are used to configure the new SMF services. A full diff marked acctadm(1M) man page is in the case directory. A prototype contract based on the existing approved contracts for the use of the SMF project private upgrade file is in the case directory. The timer is set for 14 Feb, 2008. Gary.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem ======= Extended accounting is configured at boot time by the script /etc/init.d/acctadm which reads configuration parameters from /etc/acctadm.conf. The configuration is administered using the acctadm(1M) command. There are a number of problems with the current mechanism: - extended accounting cannot be enabled persistently since Solaris does not deliver a script linked to /etc/init.d/acctadm (CR 6400978 - acctadm -u not run during boot). If a user enables extended accounting using acctadm(1M), this setting will not be preserved across reboots. To have the configuration restored at the next boot, the user has to also manually create a link from /etc/rc?.d/S??acctadm to /etc/init.d/acctadm, which is both redundant and counter-intuitive. - the existing contents of an extended accounting file are lost when extended accounting is started because the current implementation truncates the file when opening it (CR 4520887 acctadm settings should be persistent by default across reboots). This makes it hard to enable extended accounting at boot without resorting to workarounds like renaming an existing file out of the way before /etc/init.d/acctadm is run. Proposal ======== The problem with persistently enabling extended accounting will be resolved by converting acctadm to use smf(5). The conversion to SMF will introduce a new transient SMF service with three instances. Each extended accounting type will be represented by a separate instance: svc:/system/acctadm:flow Flow accounting svc:/system/acctadm:process Process accounting svc:/system/acctadm:task Task accounting Enabling extended accounting using acctadm(1M) will result in the corresponding service instance being enabled (if not yet enabled) so that the configuration will be restored at the next boot. Likewise, if the effective configuration results in accounting being disabled, the service instance will be disabled. A new option (-s) will be added to acctadm(1M) to serve as the smf(5) start method. The existing -u option to configure extended accounting from the contents of /etc/acctadm.conf will be removed as it is no longer of use. The configuration parameters in /etc/acctadm.conf will be replaced by SMF properties. Since changes to the configuration may involve changes to more than one property, the current administrative utility acctadm(1M) will remain the tool to administer the configuration. The properties and their contents are therefore classified as Project Private and are listed here for reference only: config/enabled boolean kernel accounting state config/file astring name of the accounting file config/tracked astring list of tracked resources config/untracked astring list of untracked resources The instances will be delivered in the disabled state at install time. This case will introduce new RBAC rights profiles and RBAC authorizations to allow non-root users to manage extended accounting on a per accounting type basis. Existing contents of /etc/acctadm.conf will be migrated on upgrade by adding conversion code to /var/svc/profile/upgrade in the postinstall script and bfu. If the existing contents of /etc/acctadm.conf are such that extended accounting would be enabled, the instance is enabled. /etc/acctadm.conf will be removed after conversion. As described in CR 4520887, the existing contents of an accounting file will be preserved when opening the file by no longer truncating the file in vn_open(). acctadm will verify that the contents of a file (if any) are of the requested type before opening the file. 3. Interfaces 3.1. Imported interfaces /var/svc/profile/upgrade Contracted Project Private 3.2. Exported interfaces acctadm -s Committed FMRIs svc:/system/acctadm:flow Committed svc:/system/acctadm:process Committed svc:/system/acctadm:task Committed Authorizations solaris.smf.manage.acctadm.flow Committed solaris.smf.value.acctadm.flow Committed solaris.smf.manage.acctadm.process Committed solaris.smf.value.acctadm.process Committed solaris.smf.manage.acctadm.task Committed solaris.smf.value.acctadm.task Committed Rights Profiles Extended Accounting Management (Flow) Committed Extended Accounting Management (Process) Committed Extended Accounting Management (Task) Committed acctadm Project Private 3.3. Removed interfaces acctadm -u /etc/init.d/acctadm /etc/acctadm.conf 3.4 Implementation Detail For maintainability and convenience a subprofile of the committed profiles is used to grant the /usr/sbin/acctadm command to the owners of the Extended Accounting Management * profiles: acctadm:::Do not assign to users. Commands required for \ Extended Account Management profiles.:help= ..... acctadm:solaris:cmd:::/usr/sbin/acctadm:euid=0;privs=sys_acct There is a precedent for lower case Rights Profiles to be private and used internally to the system. See the CDE profiles from Trusted Extensions. euid=0 is required to open the root owned accounting file. sys_acct is required to use acct(2) to manage accounting. 4. References acctadm(1m) diffs: OPTIONS The following options are supported: + -s Start method for the smf(5) instance. + This option is used to restore the + extended accounting configuration at + boot. - -u Configure accounting based on the con- - tents of /etc/acctadm.conf. EXIT STATUS The following exit values are returned: 2 Invalid command line options were specified. + 95 A fatal, non-configuration error occurred during start + of the smf(5) service instance. + 96 A fatal configuration error occurred during start of the + smf(5) service instance. -FILES - /etc/acctadm.conf NOTES + Extended accounting configuration is stored in the service + management facility, smf(5), repository. The configuration + is restored at boot by a transient service instance, one per + accounting type: + + svc:/system/acctadm:flow Flow accounting + svc:/system/acctadm:process Process accounting + svc:/system/acctadm:task Task accounting + + The instances are enabled or disabled by acctadm as needed. + Configuration changes are made using acctadm(1M), service + properties should not be modified directly using svccfg(1M). + + Users can manage extended accounting (start accounting, stop + accounting, change accounting configuration parameters) if + they have the appropriate RBAC Rights profile for the accounting + type to be managed: + + Extended Accounting Management (Flow) + Extended Accounting Management (Process) + Extended Accounting Management (Task) + + for flow accounting, process accounting and task accounting + respectively. PSARC 1999/119 Tasks, Projects, and Extended Accounting PSARC 2001/424 Enhancements to acctadm(1M) 5082833 RFE: exacct and acctadm should be converted to smf(5) http://bugs.opensolaris.org/view_bug.do?bug_id=5082833 6400978 acctadm -u not run during boot http://bugs.opensolaris.org/view_bug.do?bug_id=6400978 4520887 acctadm settings should be persistent by default across reboots http://bugs.opensolaris.org/view_bug.do?bug_id=4520887 From Darren.Reed@sun.com Thu Feb 7 18:12:18 2008 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 m182CHOd023592 for ; Thu, 7 Feb 2008 18:12:18 -0800 (PST) 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 m182C3RN026603 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Feb 2008 02:12:16 GMT 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 <0JVW00701E4EV500@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Feb 2008 18:12:14 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVW0067BE4CSP10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Feb 2008 18:12:13 -0800 (PST) Received: from fe-apac-04.sun.com (fe-apac-04.sun.com [192.18.19.175] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m182CIXY001121 for ; Fri, 08 Feb 2008 02:12:18 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JVW00601DSO9T00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 10:12:12 +0800 (SGT) Received: from [129.158.87.228] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JVW004Z1E4AAJB0@mail-apac.sun.com>; Fri, 08 Feb 2008 10:12:12 +0800 (SGT) Date: Fri, 08 Feb 2008 13:10:45 +1100 From: Darren Reed Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <200802072222.m17MMmTw015385@sac.sfbay.sun.com> Sender: Darren.Reed@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, Menno.Lageman@sun.com Message-id: <47ABBA25.3080405@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802072222.m17MMmTw015385@sac.sfbay.sun.com> User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) Status: RO Content-Length: 751 Gary Winiger wrote: > ... > The configuration parameters in /etc/acctadm.conf will be replaced by > SMF properties. Since changes to the configuration may involve changes > to more than one property, the current administrative utility acctadm(1M) > will remain the tool to administer the configuration. The properties > and their contents are therefore classified as Project Private and > are listed here for reference only: > > config/enabled boolean kernel accounting state > In what situations would config/enabled be true and the SMF property (general/enabled) that reflects the state of the service be false, or vice versa, thus disagreeing about the state of accounting? Or put differently, why isn't this property redundant? Darren From gww@eng.sun.com Thu Feb 7 19:11:44 2008 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 m183Bhiq024496 for ; Thu, 7 Feb 2008 19:11:44 -0800 (PST) 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 m183BZac027210 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Feb 2008 11:11:42 +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 <0JVW00M05GVFLN00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Feb 2008 20:11:39 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVW00FWDGVEFR30@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 07 Feb 2008 20:11:38 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m183BbCZ055033; Thu, 07 Feb 2008 19:11:37 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m183Bdbw020850; Thu, 07 Feb 2008 19:11:39 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m183Bdua020849; Thu, 07 Feb 2008 19:11:39 -0800 (PST) Date: Thu, 07 Feb 2008 19:11:39 -0800 (PST) From: Gary Winiger Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] To: PSARC-ext@sun.com, gww@sac.sfbay.sun.com Cc: Menno.Lageman@sun.com, glenn.faden@sun.com Message-id: <200802080311.m183Bdua020849@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 823 > I'm sponsoring this fast track for Menno Lageman. I didn't try to resolve this with the project team before starting this case because I wanted to ask it in a broader context. > Rights Profiles > Extended Accounting Management (Flow) Committed > Extended Accounting Management (Process) Committed > Extended Accounting Management (Task) Committed To date, Rights Profiles have not presented this naming syntax. They have all been without following modifiers. Such as "Audit Control" or "Audit Review" rather than "Audit Management (Control)" or "Audit Management (Review)". I don't have strong feelings either way with respect to this proposal, but wanted to ask others. Would something like "Manage Flow Extended Accounting" or "Flow Extended Accounting Management" be more appropriate naming? Gary.. From Menno.Lageman@sun.com Fri Feb 8 00:14:27 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m188ER5d001302 for ; Fri, 8 Feb 2008 00:14:27 -0800 (PST) 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 m188ERtm020604 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Feb 2008 00:14:27 -0800 (PST) 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 <0JVW00209UW36Q00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 01:14:27 -0700 (MST) Received: from gmp-eb-mail-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 <0JVW00M1ZUW2FXD0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 01:14:26 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m188EPqM024067 for ; Fri, 08 Feb 2008 08:14:25 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVW00301UTVVH00@fe-emea-09.sun.com> (original mail from Menno.Lageman@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 08:14:25 +0000 (GMT) Received: from [192.168.1.64] ([82.168.33.39]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVW00DO9UVIM640@fe-emea-09.sun.com>; Fri, 08 Feb 2008 08:14:07 +0000 (GMT) Date: Fri, 08 Feb 2008 09:14:49 +0100 From: Menno Lageman Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47ABBA25.3080405@Sun.COM> Sender: Menno.Lageman@sun.com To: Darren Reed Cc: Gary Winiger , PSARC-ext@sun.com Message-id: <47AC0F79.8010302@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802072222.m17MMmTw015385@sac.sfbay.sun.com> <47ABBA25.3080405@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 1097 Darren Reed wrote: >> >> config/enabled boolean kernel accounting state >> > > In what situations would config/enabled be true and the SMF > property (general/enabled) that reflects the state of the service > be false, or vice versa, thus disagreeing about the state of > accounting? > > Or put differently, why isn't this property redundant? > Darren, the general/enabled property only determines whether or not the configuration (whatever it may be) is restored upon boot. The config/enabled property reflects the state of accounting in the kernel (i.e. is the extended accounting subsystem active). It is perfectly valid to have a configuration with config/enabled being false (e.g. after issuing 'acctadm -D task' to temporarily stop writing accounting records while keeping the accounting file open) and general/enabled being true. Upon boot this will restore the configuration (set file name, tracked and untracked resources, do not write records). So the property config/enabled is not redundant. Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno From Darren.Moffat@sun.com Fri Feb 8 03:19:10 2008 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 m18BJ906004652 for ; Fri, 8 Feb 2008 03:19:09 -0800 (PST) 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 m18BJ9IB028070 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Feb 2008 04:19:09 -0700 (MST) 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 <0JVX0020J3FXMW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 03:19:09 -0800 (PST) Received: from gmp-eb-mail-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 <0JVX000VE3FUR000@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 03:19:07 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m18BJ5dG015112 for ; Fri, 08 Feb 2008 11:19:05 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVX00G013DNSX00@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 11:19:05 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVX00EH33FBH110@fe-emea-09.sun.com>; Fri, 08 Feb 2008 11:18:48 +0000 (GMT) Date: Fri, 08 Feb 2008 11:18:47 +0000 From: Darren J Moffat Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <200802080311.m183Bdua020849@marduk.eng.sun.com> Sender: Darren.Moffat@sun.com To: Gary Winiger Cc: PSARC-ext@sun.com, gww@sac.sfbay.sun.com, Menno.Lageman@sun.com, Glenn.Faden@sun.com Message-id: <47AC3A97.4010602@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802080311.m183Bdua020849@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 1169 Gary Winiger wrote: >> I'm sponsoring this fast track for Menno Lageman. > > I didn't try to resolve this with the project team before > starting this case because I wanted to ask it in a broader > context. > >> Rights Profiles >> Extended Accounting Management (Flow) Committed >> Extended Accounting Management (Process) Committed >> Extended Accounting Management (Task) Committed > > To date, Rights Profiles have not presented this naming > syntax. They have all been without following modifiers. > Such as "Audit Control" or "Audit Review" rather than > "Audit Management (Control)" or "Audit Management (Review)". > I don't have strong feelings either way with respect to > this proposal, but wanted to ask others. Would something > like "Manage Flow Extended Accounting" or "Flow Extended > Accounting Management" be more appropriate naming? What is the value in having 3 different rights profiles at all ? Why not just one ? We don't have multiple different levels for audit management even though we could in theory create them - manage the creation of audit trails versus config of the service vs review etc etc. -- Darren J Moffat From Menno.Lageman@sun.com Fri Feb 8 07:30:31 2008 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 m18FUUXI009457 for ; Fri, 8 Feb 2008 07:30:31 -0800 (PST) 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 m18FUS0q010857 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Feb 2008 15:30:29 GMT 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 <0JVX00D3DF2RKZ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 08:30:28 -0700 (MST) Received: from gmp-eb-mail-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 <0JVX0044DF2ALP80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 08:30:11 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m18FUAd4003913 for ; Fri, 08 Feb 2008 15:30:10 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVX00G01EF5LD00@fe-emea-10.sun.com> (original mail from Menno.Lageman@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 15:30:10 +0000 (GMT) Received: from [192.168.1.64] ([82.168.33.39]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVX00EDGF278F70@fe-emea-10.sun.com>; Fri, 08 Feb 2008 15:30:07 +0000 (GMT) Date: Fri, 08 Feb 2008 16:30:48 +0100 From: Menno Lageman Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47AC3A97.4010602@Sun.COM> Sender: Menno.Lageman@sun.com To: Darren J Moffat Cc: Gary Winiger , PSARC-ext@sun.com, Glenn.Faden@sun.com, gww@sac.sfbay.sun.com Message-id: <47AC75A8.9020503@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802080311.m183Bdua020849@marduk.eng.sun.com> <47AC3A97.4010602@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 1672 Darren J Moffat wrote: > Gary Winiger wrote: >>> I'm sponsoring this fast track for Menno Lageman. >> I didn't try to resolve this with the project team before >> starting this case because I wanted to ask it in a broader >> context. >> >>> Rights Profiles >>> Extended Accounting Management (Flow) Committed >>> Extended Accounting Management (Process) Committed >>> Extended Accounting Management (Task) Committed >> To date, Rights Profiles have not presented this naming >> syntax. They have all been without following modifiers. >> Such as "Audit Control" or "Audit Review" rather than >> "Audit Management (Control)" or "Audit Management (Review)". >> I don't have strong feelings either way with respect to >> this proposal, but wanted to ask others. Would something >> like "Manage Flow Extended Accounting" or "Flow Extended >> Accounting Management" be more appropriate naming? > > What is the value in having 3 different rights profiles at all ? Why > not just one ? This is to allow for fine grained delegation. Flow accounting and process/task accounting may possibly live in different administrative realms. Having separate rights profiles gives the ability to delegate management of just flow extended accounting to a user. Also, given the fact that enabling process extended accounting generates a huge amount of data, one might want to delegate management of only task extended accounting. Is the concern the number of new rights profiles, or the fact that to grant management of all extended accounting one needs to assign all three profiles to a user? Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno From Darren.Moffat@sun.com Fri Feb 8 07:43:58 2008 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 m18FhwFB009623 for ; Fri, 8 Feb 2008 07:43:58 -0800 (PST) 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 m18Fhwp6054391 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Feb 2008 08:43:58 -0700 (MST) 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 <0JVX00E0FFP9SO00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 08:43:57 -0700 (MST) Received: from gmp-eb-mail-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 <0JVX004N9FP7LZ90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 08:43:56 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m18FhtFI005768 for ; Fri, 08 Feb 2008 15:43:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVX00H01F5M0600@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 15:43:55 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVX000LVFP66H20@fe-emea-10.sun.com>; Fri, 08 Feb 2008 15:43:55 +0000 (GMT) Date: Fri, 08 Feb 2008 15:43:54 +0000 From: Darren J Moffat Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47AC75A8.9020503@sun.com> Sender: Darren.Moffat@sun.com To: Menno Lageman Cc: Gary Winiger , PSARC-ext@sun.com, Glenn.Faden@sun.com, gww@sac.sfbay.sun.com Message-id: <47AC78BA.6040204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802080311.m183Bdua020849@marduk.eng.sun.com> <47AC3A97.4010602@Sun.COM> <47AC75A8.9020503@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 1510 Menno Lageman wrote: >> What is the value in having 3 different rights profiles at all ? Why >> not just one ? > > This is to allow for fine grained delegation. Flow accounting and > process/task accounting may possibly live in different administrative > realms. Having separate rights profiles gives the ability to delegate > management of just flow extended accounting to a user. Also, given the > fact that enabling process extended accounting generates a huge amount > of data, one might want to delegate management of only task extended > accounting. > > Is the concern the number of new rights profiles, or the fact that to > grant management of all extended accounting one needs to assign all > three profiles to a user? Neither really just trying to determine if there was even a need to be that fine grained given this was never possible before this case. If it is a requirement that each of these can be delegated to different users then I'm happy that there be multiple profiles to do so. With that in mind my suggestion is that the profiles are: Accounting Management: This includes three (Committed) sub profiles Accounting Flow Management Accounting Process Management Accounting Task Management Each of the sub profiles includes the private "acctadm" profile too. Notice that I dropped the "Extended" prefix. Is that really necessary ? The admin command is acctadm(1M) not eacctadm(1M), similarly the SMF FMRI doesn't have extended mentioned. -- Darren J Moffat From Menno.Lageman@sun.com Fri Feb 8 08:03:27 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m18G3Rdc010192 for ; Fri, 8 Feb 2008 08:03:27 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m18G3R1L012289 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Feb 2008 08:03:27 -0800 (PST) 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 <0JVX00603GLPKF00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 08:03:25 -0800 (PST) Received: from gmp-eb-mail-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 <0JVX000ANGLLQRE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 08:03:25 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m18G3LG7018480 for ; Fri, 08 Feb 2008 16:03:21 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVX00F01GGLGL00@fe-emea-10.sun.com> (original mail from Menno.Lageman@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 16:03:21 +0000 (GMT) Received: from [192.168.1.64] ([82.168.33.39]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVX002JNGLGNW50@fe-emea-10.sun.com>; Fri, 08 Feb 2008 16:03:17 +0000 (GMT) Date: Fri, 08 Feb 2008 17:03:59 +0100 From: Menno Lageman Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47AC78BA.6040204@Sun.COM> Sender: Menno.Lageman@sun.com To: Darren J Moffat Cc: Gary Winiger , PSARC-ext@sun.com, Glenn.Faden@sun.com, gww@sac.sfbay.sun.com Message-id: <47AC7D6F.9010008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802080311.m183Bdua020849@marduk.eng.sun.com> <47AC3A97.4010602@Sun.COM> <47AC75A8.9020503@sun.com> <47AC78BA.6040204@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 2145 Darren J Moffat wrote: > Menno Lageman wrote: >>> What is the value in having 3 different rights profiles at all ? Why >>> not just one ? >> >> This is to allow for fine grained delegation. Flow accounting and >> process/task accounting may possibly live in different administrative >> realms. Having separate rights profiles gives the ability to delegate >> management of just flow extended accounting to a user. Also, given the >> fact that enabling process extended accounting generates a huge amount >> of data, one might want to delegate management of only task extended >> accounting. >> >> Is the concern the number of new rights profiles, or the fact that to >> grant management of all extended accounting one needs to assign all >> three profiles to a user? > > Neither really just trying to determine if there was even a need to be > that fine grained given this was never possible before this case. If it > is a requirement that each of these can be delegated to different users > then I'm happy that there be multiple profiles to do so. > > With that in mind my suggestion is that the profiles are: > > Accounting Management: This includes three (Committed) sub profiles > Accounting Flow Management > Accounting Process Management > Accounting Task Management > > Each of the sub profiles includes the private "acctadm" profile too. > > Notice that I dropped the "Extended" prefix. Is that really necessary ? > The admin command is acctadm(1M) not eacctadm(1M), similarly the SMF > FMRI doesn't have extended mentioned. > Dropping the "Extended" prefix may lead to confusion with the 'classic' accounting described in acct(1M). And the subsystem managed by acctadm(1M) is called Extended Accounting, so having that in the name seems the logical thing to do. The SMF FMRI does not contain the word "accounting" for the same reason. I entertained the thought of using "extended accounting" in the FMRI but decided that was too long to be useful. Instead, I followed the convention used for the FMRI for coreadm(1M). Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno From Darren.Moffat@sun.com Fri Feb 8 08:18:31 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m18GIVKH011629 for ; Fri, 8 Feb 2008 08:18:31 -0800 (PST) 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 m18GIUZp020927 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 8 Feb 2008 08:18:31 -0800 (PST) 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 <0JVX00H0JHAUFJ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 09:18:30 -0700 (MST) Received: from gmp-eb-mail-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 <0JVX004GEHATLRB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 09:18:30 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m18GITq7010599 for ; Fri, 08 Feb 2008 16:18:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVX00E01FSKUY00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 16:18:29 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVX000S2HAR6H20@fe-emea-10.sun.com>; Fri, 08 Feb 2008 16:18:28 +0000 (GMT) Date: Fri, 08 Feb 2008 16:18:27 +0000 From: Darren J Moffat Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47AC7D6F.9010008@sun.com> Sender: Darren.Moffat@sun.com To: Menno Lageman Cc: Gary Winiger , PSARC-ext@sun.com, Glenn.Faden@sun.com, gww@sac.sfbay.sun.com Message-id: <47AC80D3.5060900@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802080311.m183Bdua020849@marduk.eng.sun.com> <47AC3A97.4010602@Sun.COM> <47AC75A8.9020503@sun.com> <47AC78BA.6040204@Sun.COM> <47AC7D6F.9010008@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 1437 Menno Lageman wrote: > Dropping the "Extended" prefix may lead to confusion with the 'classic' > accounting described in acct(1M). And the subsystem managed by > acctadm(1M) is called Extended Accounting, so having that in the name > seems the logical thing to do. I actually think it is the opposite. The command isn't extendedacctadm or eacctadm it is just acctadm. I think the Extended prefix is useless in the RBAC profile name and only adds to the confusion already created by having both acct(1M) and acctadm(1M) referring to different generations of the subsystem. In RBAC profile naming we already have precedence for multiple 'generations' being covered by a single profile. Consider the 'Name Services Security' profile it covers commands used in NIS, NIS+ and LDAP. > The SMF FMRI does not contain the word "accounting" for the same reason. > I entertained the thought of using "extended accounting" in the FMRI but > decided that was too long to be useful. Instead, I followed the > convention used for the FMRI for coreadm(1M). Now that you mention it I think that it should be called accounting in the FMRI. The practice of naming the FMRI after the current CLI implementation used to control it isn't so good in my opinion, the FMRI should describe the service not the admin interface command, eg it is network/ssh not network/sshd and network/system-log not network/syslogd. -- Darren J Moffat From Menno.Lageman@sun.com Fri Feb 8 08:18:48 2008 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 m18GIl5G011647 for ; Fri, 8 Feb 2008 08:18:48 -0800 (PST) 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 m18GIgMs024340 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 9 Feb 2008 00:18:46 +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 <0JVX00H01HB6GE00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 09:18:42 -0700 (MST) Received: from gmp-eb-mail-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 <0JVX004K4HB5LOB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 09:18:42 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m18GIfWP010635 for ; Fri, 08 Feb 2008 16:18:41 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVX00H01HATQU00@fe-emea-10.sun.com> (original mail from Menno.Lageman@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 08 Feb 2008 16:18:41 +0000 (GMT) Received: from [192.168.1.64] ([82.168.33.39]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVX00251HB4NWC0@fe-emea-10.sun.com>; Fri, 08 Feb 2008 16:18:40 +0000 (GMT) Date: Fri, 08 Feb 2008 17:19:22 +0100 From: Menno Lageman Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47AC78BA.6040204@Sun.COM> Sender: Menno.Lageman@sun.com To: Darren J Moffat Cc: PSARC-ext@sun.com, Glenn.Faden@sun.com, gww@sac.sfbay.sun.com, Gary Winiger Message-id: <47AC810A.2000306@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802080311.m183Bdua020849@marduk.eng.sun.com> <47AC3A97.4010602@Sun.COM> <47AC75A8.9020503@sun.com> <47AC78BA.6040204@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 495 Darren J Moffat wrote: > > With that in mind my suggestion is that the profiles are: > > Accounting Management: This includes three (Committed) sub profiles > Accounting Flow Management > Accounting Process Management > Accounting Task Management > (hit send too quickly) The suggestion of renaming from 'Extended Accounting Management (Flow)' to 'Extended Accounting Flow Management' seems a good one. Thanks, Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno From Darren.Reed@sun.com Fri Feb 8 11:41:34 2008 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 m18JfXW6017255 for ; Fri, 8 Feb 2008 11:41:34 -0800 (PST) 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 m18JfG4p010656 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 9 Feb 2008 03:41: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 <0JVX00901QP79F00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 08 Feb 2008 11:41:31 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVX004EEQP5SN70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 08 Feb 2008 11:41:30 -0800 (PST) Received: from fe-apac-03.sun.com (fe-apac-03.sun.com [192.18.19.174] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m18JfVac001465 for ; Fri, 08 Feb 2008 19:41:31 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JVX00901OPNLA00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Sat, 09 Feb 2008 03:41:29 +0800 (SGT) Received: from [129.158.87.228] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JVX00AAOQP3TQ35@mail-apac.sun.com>; Sat, 09 Feb 2008 03:41:29 +0800 (SGT) Date: Sat, 09 Feb 2008 06:40:00 +1100 From: Darren Reed Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47AC0F79.8010302@sun.com> Sender: Darren.Reed@sun.com To: Menno Lageman Cc: Gary Winiger , PSARC-ext@sun.com Message-id: <47ACB010.1010001@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802072222.m17MMmTw015385@sac.sfbay.sun.com> <47ABBA25.3080405@Sun.COM> <47AC0F79.8010302@sun.com> User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) Status: RO Content-Length: 1674 Menno Lageman wrote: > Darren Reed wrote: >>> >>> config/enabled boolean kernel accounting state >>> >> >> In what situations would config/enabled be true and the SMF >> property (general/enabled) that reflects the state of the service >> be false, or vice versa, thus disagreeing about the state of >> accounting? >> >> Or put differently, why isn't this property redundant? >> > > Darren, > > the general/enabled property only determines whether or not the > configuration (whatever it may be) is restored upon boot. The > config/enabled property reflects the state of accounting in the kernel > (i.e. is the extended accounting subsystem active). > > It is perfectly valid to have a configuration with config/enabled > being false (e.g. after issuing 'acctadm -D task' to temporarily stop > writing accounting records while keeping the accounting file open) and > general/enabled being true. Upon boot this will restore the > configuration (set file name, tracked and untracked resources, do not > write records). So the property config/enabled is not redundant. I must have picked the wrong property... there is one that reflects the current status...anyway... Why is acctadm the administrative interface here and not svcadm? Why wouldn't you use "svcadm disable -t system/acctadm:flow" ? Or is your point that "acctadm -D task" temporarily disables all three? And to ask the question I was asking in a different way, can config/enabled be different to the status of the service as observed using svcs? And if not, doesn't that then make config/enabled redundant? And if yes, does it make sense for the two to be able to disagree? Darren From Menno.Lageman@sun.com Fri Feb 8 13:35:15 2008 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 m18LZEgT021159 for ; Fri, 8 Feb 2008 13:35:15 -0800 (PST) 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 m18LYroh021527 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 9 Feb 2008 05:35:13 +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 <0JVX00J1FVYM6T00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 08 Feb 2008 14:35:10 -0700 (MST) Received: from gmp-eb-mail-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 <0JVX00HNWVYKEQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Fri, 08 Feb 2008 14:35:09 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m18LZ8fv027555 for ; Fri, 08 Feb 2008 21:35:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVX00001VSDDQ00@fe-emea-10.sun.com> (original mail from Menno.Lageman@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Fri, 08 Feb 2008 21:35:08 +0000 (GMT) Received: from [192.168.1.64] ([82.168.33.39]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVX00AOIVYJNC60@fe-emea-10.sun.com>; Fri, 08 Feb 2008 21:35:08 +0000 (GMT) Date: Fri, 08 Feb 2008 22:35:49 +0100 From: Menno Lageman Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47ACB010.1010001@Sun.COM> Sender: Menno.Lageman@sun.com To: Darren Reed Cc: PSARC-ext@sun.com, Gary Winiger Message-id: <47ACCB35.20409@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802072222.m17MMmTw015385@sac.sfbay.sun.com> <47ABBA25.3080405@Sun.COM> <47AC0F79.8010302@sun.com> <47ACB010.1010001@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 4658 Darren Reed wrote: > Menno Lageman wrote: >> Darren Reed wrote: >>>> config/enabled boolean kernel accounting state >>>> >>> In what situations would config/enabled be true and the SMF >>> property (general/enabled) that reflects the state of the service >>> be false, or vice versa, thus disagreeing about the state of >>> accounting? >>> >>> Or put differently, why isn't this property redundant? >>> >> Darren, >> >> the general/enabled property only determines whether or not the >> configuration (whatever it may be) is restored upon boot. The >> config/enabled property reflects the state of accounting in the kernel >> (i.e. is the extended accounting subsystem active). >> >> It is perfectly valid to have a configuration with config/enabled >> being false (e.g. after issuing 'acctadm -D task' to temporarily stop >> writing accounting records while keeping the accounting file open) and >> general/enabled being true. Upon boot this will restore the >> configuration (set file name, tracked and untracked resources, do not >> write records). So the property config/enabled is not redundant. > > I must have picked the wrong property... there is one that reflects > the current status...anyway... I think you have picked the right one. However the current 'state' of extended accounting is not just config/enabled, it is the set of config/enabled, config/file, config/tracked, and config/untracked together that makes up the state of extended accounting for a particular type. > Why is acctadm the administrative interface here and not svcadm? svcadm can only handle enable/disable of the instance; managing extended accounting however encompasses more than just enable/disable. It also allows specifying what resources to track, what file to write the accounting records to etc. acctadm(1M) does all this. The 'smf state' (i.e. the general/enabled property) of the instance only determines whether or not we restore the last active extended accounting configuration on the next reboot, nothing more. Compare it to svc:/system/coreadm:default if you will: if it is enabled, the configuration previously set using coreadm(1M) is restored on reboot. > Why wouldn't you use "svcadm disable -t system/acctadm:flow" ? This wouldn't be particularly useful since these are transient services that perform a configuration action at boot only (disable -t only lasts until the next reboot). There is no daemon running for them when the instance is enabled. It is not forbidden to use svcadm enable/disable on the instance, it is just that svcadm isn't rich enough to perform all configuration actions one would want to do wrt configuring extended accounting. > Or is your point that "acctadm -D task" temporarily disables all three? > > And to ask the question I was asking in a different way, > can config/enabled be different to the status of the service > as observed using svcs? Yes it can. To quote my previous example, assume an admin has enabled extended task accounting as follows: acctadm -e basic -f /var/adm/exacct/task task This will: - enable extended accounting in the kernel for tasks, - open /var/adm/exacct/task to receive task accounting records, - set the tracked resources the resources in the basic set, - set the config/enabled property to 'true', - set the config/file property to '/var/adm/exacct/task', - set the config/tracked property to 'basic', - enable svc:/system/acctadm:task so the configuration is restored on the next boot (thus setting general/enabled to 'true'). The admin can then use 'acctadm -D task' to stop writing accounting records without closing the accounting file (this is existing functionality btw, not something introduced by this case. See PSARC/2001/424 for a state diagram). This will: - disable extended accounting in the kernel for tasks, - set the config/enabled property to 'false'. The instance will remain enabled since there still is configuration (i.e. the accounting file name and the tracked resources) to restore on boot. > And if not, doesn't that then make config/enabled redundant? And if yes, does it make sense > for the two to be able to disagree? Yes. The key point is that general/enabled *only* determines whether the configuration is applied on the next reboot or not. Nothing more. There is normally no need to use svcadm(1M) to manage extended accounting, everything is handled by acctadm(1M). If you enable extended accounting, acctadm(1M) will enable the instance so the configuration is restored the next time the system is booted. Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno From Menno.Lageman@sun.com Sat Feb 9 11:10:09 2008 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 m19JA9qW009102 for ; Sat, 9 Feb 2008 11:10:09 -0800 (PST) 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 m19JA7t1014256 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 9 Feb 2008 19:10:07 GMT 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 <0JVZ0060FJWUUZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 09 Feb 2008 11:10:06 -0800 (PST) Received: from gmp-eb-mail-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 <0JVZ00HTPJWTKT60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 09 Feb 2008 11:10:06 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m19JA4Df021039 for ; Sat, 09 Feb 2008 19:10:04 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVZ00601JRZUN00@fe-emea-09.sun.com> (original mail from Menno.Lageman@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 09 Feb 2008 19:10:04 +0000 (GMT) Received: from [192.168.1.64] ([82.168.33.39]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVZ00EQ3JWR3CE0@fe-emea-09.sun.com>; Sat, 09 Feb 2008 19:10:04 +0000 (GMT) Date: Sat, 09 Feb 2008 20:10:48 +0100 From: Menno Lageman Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47AC80D3.5060900@Sun.COM> Sender: Menno.Lageman@sun.com To: Darren J Moffat Cc: Gary Winiger , PSARC-ext@sun.com, Glenn.Faden@sun.com, gww@sac.sfbay.sun.com Message-id: <47ADFAB8.7070005@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802080311.m183Bdua020849@marduk.eng.sun.com> <47AC3A97.4010602@Sun.COM> <47AC75A8.9020503@sun.com> <47AC78BA.6040204@Sun.COM> <47AC7D6F.9010008@sun.com> <47AC80D3.5060900@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 3771 Darren J Moffat wrote: > Menno Lageman wrote: >> Dropping the "Extended" prefix may lead to confusion with the >> 'classic' accounting described in acct(1M). And the subsystem managed >> by acctadm(1M) is called Extended Accounting, so having that in the >> name seems the logical thing to do. > > I actually think it is the opposite. The command isn't extendedacctadm > or eacctadm it is just acctadm. The fact that the command isn't called extendedacctadm or eacctadm does not mean that the subsystem can thus not be named Extended Accounting. It has been called Extended Accounting since PSARC 1999/119 (Tasks, Projects, and Extended Accounting), it is referred to as Extended Accounting in the documentation (chapter 4 of the System Administration Guide: Solaris Containers-Resource Management and Solaris Zones) and in the acctadm(1M) man page. Yes, it might have been better if acctadm(1M) had been named otherwise when it was introduced by PSARC 1999/119, but that does not mean we should now drop the "Extended" prefix and refer to it as just Accounting (which is a separate set of tools). > > I think the Extended prefix is useless in the RBAC profile name and only > adds to the confusion already created by having both acct(1M) and > acctadm(1M) referring to different generations of the subsystem. I think that leaving out the Extended prefix in the RBAC profiles only increases the confusion, because we then say Accounting when in fact we mean Extended Accounting (the service manages the Extended Accounting subsystem, not the classic accounting tools). > In RBAC profile naming we already have precedence for multiple > 'generations' being covered by a single profile. Consider the 'Name > Services Security' profile it covers commands used in NIS, NIS+ and LDAP. Understood, but I still think the opportunity for confusion is just to big without the Extended prefix. Does the 'Accounting Process Management' RBAC profile refer to process accounting as described in chapter 16 of the Solaris Administration Guide: Advanced Administration or does it refer to the process accounting component of the Extended Accounting facility described in chapter 4 of the System Administration Guide: Solaris Containers-Resource Management and Solaris Zones? By keeping the prefix we make it unambigous. >> The SMF FMRI does not contain the word "accounting" for the same >> reason. I entertained the thought of using "extended accounting" in >> the FMRI but decided that was too long to be useful. Instead, I >> followed the convention used for the FMRI for coreadm(1M). > > Now that you mention it I think that it should be called accounting in > the FMRI. The practice of naming the FMRI after the current CLI > implementation used to control it isn't so good in my opinion, the FMRI > should describe the service not the admin interface command, eg it is > network/ssh not network/sshd and network/system-log not network/syslogd. I don't think the FMRI should be svc:/system/accounting:process for the same reason outlined above. These services do not manage Accounting, they manage Extended Accounting. If using the name of the administrative command in the FMRI is frowned upon, then perhaps the FMRIs should be of the form svc:/system/extended-accounting:process. So I propose to change the names of the RBAC profiles to: Extended Accounting Flow Management Extended Accounting Process Management Extended Accounting Task Management (i.e. Darren's suggestion, however with the prefix). And to change the FMRIs to: svc:/system/extended-accounting:flow svc:/system/extended-accounting:process svc:/system/extended-accounting:task Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno From isaac@sun.com Sat Feb 9 11:28:13 2008 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 m19JSCC1009409 for ; Sat, 9 Feb 2008 11:28:12 -0800 (PST) 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 m19JS3dB017432 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 9 Feb 2008 19:28:11 GMT 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 <0JVZ00701KQXO100@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 09 Feb 2008 11:28:09 -0800 (PST) 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 <0JVZ00H00KQWKM70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 09 Feb 2008 11:28:09 -0800 (PST) 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 m19JS8Pf005358 for ; Sat, 09 Feb 2008 19:28:08 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVZ00601KHM6500@mail-amer.sun.com> (original mail from isaac@sun.com) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Sat, 09 Feb 2008 12:28:08 -0700 (MST) Received: from [10.150.121.87] (mobile-032-139-124-197.mycingular.net [32.139.124.197]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVZ00MLTKQSJ600@mail-amer.sun.com>; Sat, 09 Feb 2008 12:28:08 -0700 (MST) Date: Sat, 09 Feb 2008 14:27:39 -0500 From: Isaac Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47ADFAB8.7070005@sun.com> Sender: Isaac.Rozenfeld@sun.com To: Menno Lageman Cc: Darren J Moffat , Gary Winiger , "PSARC-ext@sun.com" , "Glenn.Faden@Sun.COM" , "gww@sac.sfbay.sun.com" Message-id: <0460B96D-8962-41BD-B4EB-C426E548A8F4@sun.com> MIME-version: 1.0 X-Mailer: iPhone Mail (1C28) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802080311.m183Bdua020849@marduk.eng.sun.com> <47AC3A97.4010602@Sun.COM> <47AC75A8.9020503@sun.com> <47AC78BA.6040204@Sun.COM> <47AC7D6F.9010008@sun.com> <47AC80D3.5060900@Sun.COM> <47ADFAB8.7070005@sun.com> Status: RO Content-Length: 4025 Agreed. On Feb 9, 2008, at 2:10 PM, Menno Lageman wrote: > Darren J Moffat wrote: >> Menno Lageman wrote: >>> Dropping the "Extended" prefix may lead to confusion with the >>> 'classic' accounting described in acct(1M). And the subsystem >>> managed by acctadm(1M) is called Extended Accounting, so having >>> that in the name seems the logical thing to do. >> I actually think it is the opposite. The command isn't >> extendedacctadm or eacctadm it is just acctadm. > > The fact that the command isn't called extendedacctadm or eacctadm > does not mean that the subsystem can thus not be named Extended > Accounting. It has been called Extended Accounting since PSARC > 1999/119 (Tasks, Projects, and Extended Accounting), it is referred > to as Extended Accounting in the documentation (chapter 4 of the > System Administration Guide: Solaris Containers-Resource Management > and Solaris Zones) and in the acctadm(1M) man page. > > Yes, it might have been better if acctadm(1M) had been named > otherwise when it was introduced by PSARC 1999/119, but that does > not mean we should now drop the "Extended" prefix and refer to it as > just Accounting (which is a separate set of tools). > >> I think the Extended prefix is useless in the RBAC profile name and >> only adds to the confusion already created by having both acct(1M) >> and acctadm(1M) referring to different generations of the subsystem. > > I think that leaving out the Extended prefix in the RBAC profiles > only increases the confusion, because we then say Accounting when in > fact we mean Extended Accounting (the service manages the Extended > Accounting subsystem, not the classic accounting tools). > >> In RBAC profile naming we already have precedence for multiple >> 'generations' being covered by a single profile. Consider the >> 'Name Services Security' profile it covers commands used in NIS, NIS >> + and LDAP. > > Understood, but I still think the opportunity for confusion is just > to big without the Extended prefix. Does the 'Accounting Process > Management' RBAC profile refer to process accounting as described in > chapter 16 of the Solaris Administration Guide: Advanced > Administration or does it refer to the process accounting component > of the Extended Accounting facility described in chapter 4 of the > System Administration Guide: Solaris Containers-Resource Management > and Solaris Zones? By keeping the prefix we make it unambigous. > >>> The SMF FMRI does not contain the word "accounting" for the same >>> reason. I entertained the thought of using "extended accounting" >>> in the FMRI but decided that was too long to be useful. Instead, I >>> followed the convention used for the FMRI for coreadm(1M). >> Now that you mention it I think that it should be called accounting >> in the FMRI. The practice of naming the FMRI after the current CLI >> implementation used to control it isn't so good in my opinion, the >> FMRI should describe the service not the admin interface command, >> eg it is network/ssh not network/sshd and network/system-log not >> network/syslogd. > > I don't think the FMRI should be svc:/system/accounting:process for > the same reason outlined above. These services do not manage > Accounting, they manage Extended Accounting. If using the name of > the administrative command in the FMRI is frowned upon, then perhaps > the FMRIs should be of the form svc:/system/extended- > accounting:process. > > So I propose to change the names of the RBAC profiles to: > Extended Accounting Flow Management > Extended Accounting Process Management > Extended Accounting Task Management > > (i.e. Darren's suggestion, however with the prefix). > > And to change the FMRIs to: > svc:/system/extended-accounting:flow > svc:/system/extended-accounting:process > svc:/system/extended-accounting:task > > Menno > -- > Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno From Darren.Reed@sun.com Mon Feb 11 22:32:10 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1C6WA3n019569 for ; Mon, 11 Feb 2008 22:32:10 -0800 (PST) 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 m1C6W8Gf019268 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 11 Feb 2008 22:32:10 -0800 (PST) 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 <0JW400F0N4TKYW00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 11 Feb 2008 22:32:08 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW400M5A4TJ9YC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 11 Feb 2008 22:32:08 -0800 (PST) Received: from fe-apac-01.sun.com (fe-apac-01.sun.com [192.18.19.172] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1C6WFKP011239 for ; Tue, 12 Feb 2008 06:32:15 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JW4008014K7D900@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 12 Feb 2008 14:32:06 +0800 (SGT) Received: from [129.158.87.228] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JW40082P4THFCD0@mail-apac.sun.com>; Tue, 12 Feb 2008 14:32:06 +0800 (SGT) Date: Tue, 12 Feb 2008 17:30:32 +1100 From: Darren Reed Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47ACCB35.20409@sun.com> Sender: Darren.Reed@sun.com To: Menno Lageman Cc: PSARC-ext@sun.com, Gary Winiger Message-id: <47B13D08.3050507@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802072222.m17MMmTw015385@sac.sfbay.sun.com> <47ABBA25.3080405@Sun.COM> <47AC0F79.8010302@sun.com> <47ACB010.1010001@Sun.COM> <47ACCB35.20409@sun.com> User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) Status: RO Content-Length: 3663 Menno Lageman wrote: > Darren Reed wrote: > ... >> Why wouldn't you use "svcadm disable -t system/acctadm:flow" ? > > This wouldn't be particularly useful since these are transient > services that perform a configuration action at boot only (disable -t > only lasts until the next reboot). There is no daemon running for them > when the instance is enabled. It isn't necessary for there to be a running daemon to have an SMF instance report itself as being "enabled." But my reading of the materials indicates that "diable -t" is roughly equivalent to what happens with the "-D" switch for acctadm. > It is not forbidden to use svcadm enable/disable on the instance, it > is just that svcadm isn't rich enough to perform all configuration > actions one would want to do wrt configuring extended accounting. > >> Or is your point that "acctadm -D task" temporarily disables all three? >> >> And to ask the question I was asking in a different way, >> can config/enabled be different to the status of the service >> as observed using svcs? > > Yes it can. To quote my previous example, assume an admin has enabled > extended task accounting as follows: > > acctadm -e basic -f /var/adm/exacct/task task > > This will: > - enable extended accounting in the kernel for tasks, > - open /var/adm/exacct/task to receive task accounting records, > - set the tracked resources the resources in the basic set, > - set the config/enabled property to 'true', > - set the config/file property to '/var/adm/exacct/task', > - set the config/tracked property to 'basic', > - enable svc:/system/acctadm:task so the configuration is restored on > the next boot (thus setting general/enabled to 'true'). > > The admin can then use 'acctadm -D task' to stop writing accounting > records without closing the accounting file (this is existing > functionality btw, not something introduced by this case. See > PSARC/2001/424 for a state diagram). > > This will: > - disable extended accounting in the kernel for tasks, > - set the config/enabled property to 'false'. > > The instance will remain enabled since there still is configuration > (i.e. the accounting file name and the tracked resources) to restore > on boot. This is a problem. What I see here is that you're putting a layer on top of SMF but there are problems with how that layer talks with SMF. To expand upon your above example, if you do: # acctadm -D task then shouldn't this command: # svcs -x svc:/system/acctadm:task also say that the SMF instance is temporarily offline? Why should a user be forced to do: svcprop -c -p config/enabled svc:/system/acctadm:task in order to find out what the current state of accounting is because svcs doesn't tell the whole story? Why is it necessary to use a different administative interface (check the config/enabled property) of this SMF instance to observe its state than for other services managed by SMF (ie svcs)? In your proposed model, if I do "svcs -a | grep offline", or similar, accounting that has been disabled via acctadm (using -D) will have its running state incorrectly reported. This and that I have to use another command to correctly determine the state of accounting is of great concern. Is there a reason why the model can't be: - use acctadm to provide an easy way to manage the properties of the extending accounting services; - use acctadm to start/stop extended accounting when called from the appropriate SMF method (if so desired); - use svcadm to manage the current "running state". Darren p.s. I'm going to be travelling for the next few days so expect some silence w.r.t email until after the holiday weekend (USA). From Menno.Lageman@sun.com Tue Feb 12 10:26:44 2008 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 m1CIQhGl015660 for ; Tue, 12 Feb 2008 10:26:44 -0800 (PST) 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 m1CIQfZ9016337 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 13 Feb 2008 02:26:42 +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 <0JW500K0H1WHBQ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 12 Feb 2008 11:26:41 -0700 (MST) Received: from gmp-eb-mail-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 <0JW500A651WDVW90@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Tue, 12 Feb 2008 11:26:37 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1CIQatm002477 for ; Tue, 12 Feb 2008 18:26:36 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW5007011VSUK00@fe-emea-09.sun.com> (original mail from Menno.Lageman@Sun.COM) for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Tue, 12 Feb 2008 18:26:36 +0000 (GMT) Received: from [192.168.1.64] ([82.168.33.39]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW50074A1WBST00@fe-emea-09.sun.com>; Tue, 12 Feb 2008 18:26:36 +0000 (GMT) Date: Tue, 12 Feb 2008 19:27:20 +0100 From: Menno Lageman Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47B13D08.3050507@Sun.COM> Sender: Menno.Lageman@sun.com To: Darren Reed Cc: PSARC-ext@sun.com, Gary Winiger Message-id: <47B1E508.7040309@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802072222.m17MMmTw015385@sac.sfbay.sun.com> <47ABBA25.3080405@Sun.COM> <47AC0F79.8010302@sun.com> <47ACB010.1010001@Sun.COM> <47ACCB35.20409@sun.com> <47B13D08.3050507@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 6930 Darren Reed wrote: > Menno Lageman wrote: >> Darren Reed wrote: >> ... >>> Why wouldn't you use "svcadm disable -t system/acctadm:flow" ? >> >> This wouldn't be particularly useful since these are transient >> services that perform a configuration action at boot only (disable -t >> only lasts until the next reboot). There is no daemon running for them >> when the instance is enabled. > > It isn't necessary for there to be a running daemon to have > an SMF instance report itself as being "enabled." Yes I know that. That's not what I said however; what I said is that temporarily disabling the instance isn't particularly useful here because: a) disabling the instance (for this particular service) *only* means 'do not apply the extended accounting configuration on boot' because its start method will not run at next boot. It does not twiddle any bits in the kernel at the time you disable the instance (nor is there a running daemon to do such twiddling, because this is a transient service), b) the effect of svcadm disable -t only lasts until the next reboot by definition, i.e. if the instance is currently enabled, disable -t will disable the instance until the next boot, at which time the instance will be enabled again (because you only temporarily disabled the instance). Since it doesn't twiddle any bits when being svcadm disabled, the net effect is zero. Hence the not 'particularly useful'. > But my reading of the materials indicates that "diable -t" > is roughly equivalent to what happens with the "-D" switch > for acctadm. No, it is not. svcadm disable -t has no impact on the active in-kernel configuration. acctadm -D does. > This is a problem. > > What I see here is that you're putting a layer on top of SMF No I'm not, I'm using the services provided by smf(5). This is no different from what e.g. the svc:/system/coreadm service does. There the configuration properties themselves are managed using coreadm(1M), to see the current coreadm configuration, one uses 'coreadm'. Disabling svc:/system/coreadm:default *only* means that the coreadm config is not applied at the next boot because its start method, which applies the saved config using coreadm -u, does not run. Issuing a 'coreadm -d global' updates the in-kernel state, it does not disable the service instance. Even if you'd 'svcadm disable coreadm' nothing would happen to the in-kernel state because the service has no stop method. You will only prevent the last active configuration from being applied at boot. This extended accounting service does exactly the same, so we're not inventing something new here. The difference is that the coreadm service is always enabled and never disabled, while the acctadm service is disabled until the administrator enables extended accounting using acctadm(1M), at which time the corresponding service instance is enabled since there is now configuration to apply at the next boot. > To expand upon your above example, if you do: > # acctadm -D task > then shouldn't this command: > # svcs -x svc:/system/acctadm:task > also say that the SMF instance is temporarily offline? No, see above. Disabling the instance only means 'do not apply the configuration at boot'. > Why should a user be forced to do: > svcprop -c -p config/enabled svc:/system/acctadm:task > in order to find out what the current state of accounting > is because svcs doesn't tell the whole story? The user *isn't* forced to use svcprop to find out the state, they are actually discouraged from doing so. They should use acctadm(1M) to find out about the state of extended accounting: ml93401@kahless $ acctadm Task accounting: active Task accounting file: /var/adm/exacct/task Tracked task resources: basic Untracked task resources: host,mstate,anctaskid,zone Process accounting: inactive Process accounting file: /var/adm/exacct/process Tracked process resources: none Untracked process resources: extended,host Flow accounting: inactive Flow accounting file: none Tracked flow resources: none Untracked flow resources: extended This is how it works today and how it will keep working after this case. In fact, this case classifies the config/* properties as Project Private just for this reason. The user is not expected to modify/observe these properties using smf(5) tools such as svccfg and svcprop. They should do so using the existing interface provided by acctadm(1M). > Why is it necessary to use a different administative > interface (check the config/enabled property) of this > SMF instance to observe its state than for other services > managed by SMF (ie svcs)? It isn't necessary to check config/enabled (or any other property) at all to observe the state of extended accounting: acctadm(1M) is the interface that provides this information (now and in the future). The reason being that the value of 'config/enabled' by itself does not completely represent the state of extended accounting. The config/file, config/tracked, and config/untracked properties are part of its state too. Only if config/enabled is false *and* config/file is unset *and* config/tracked is unset, can extended accounting be considered 'not active'. At that time only, the service instance will be 'disabled' in the smf sense of the word since there is no effective configuration to apply at boot. All other combinations of these four config properties result in extended accounting being 'active', thus resulting in the service instance being 'enabled' (again, in the smf sense of the word) because there is configuration to apply at boot. The enabling/disabling of the service instance is done by acctadm(1M) as a result of the user calling acctadm with the appropriate arguments to modify the configuration. > In your proposed model, if I do "svcs -a | grep offline", > or similar, accounting that has been disabled via acctadm > (using -D) will have its running state incorrectly reported. No. The enabled/disabled state of the instance (general/enabled) only signifies 'restore the configuration at boot or not'. > This and that I have to use another command to correctly > determine the state of accounting is of great concern. No, you only need *one* command to manage and determine the state of extended accounting: acctadm(1M). An unadorned 'acctadm' will tell you the state of the extended accounting configuration. Just like it does today. > Is there a reason why the model can't be: > - use acctadm to provide an easy way to manage the properties > of the extending accounting services; That is exactly the model this case provides. The smf state (general/enabled) is only interesting insofar as to see whether or not the current configuration will be applied on the next boot. Nothing more. Menno -- Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno From gww@eng.sun.com Tue Feb 19 17:13:35 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1K1DZtB010828 for ; Tue, 19 Feb 2008 17:13:35 -0800 (PST) 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 m1K1DXxo007686 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 19 Feb 2008 17:13:35 -0800 (PST) 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 <0JWI00F0FJEMV700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 19 Feb 2008 18:13:34 -0700 (MST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWI00818JEK4C80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 19 Feb 2008 18:13:32 -0700 (MST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1K1DUMd013321; Tue, 19 Feb 2008 17:13:30 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m1K1DpcQ017738; Tue, 19 Feb 2008 17:13:51 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m1K1DpTS017737; Tue, 19 Feb 2008 17:13:51 -0800 (PST) Date: Tue, 19 Feb 2008 17:13:51 -0800 (PST) From: Gary Winiger Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] To: PSARC-ext@sun.com, gww@sac.sfbay.sun.com Cc: Menno.Lageman@sun.com Message-id: <200802200113.m1K1DpTS017737@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 534 > The timer is set for 14 Feb, 2008. It seems the case has converged. The proposal is changed to have a service name of "extended-accounting" rather than "acctadm". The authorization names are also changed to reflect the service name. Rights Profile names have been renamed to "Extended Accounting Flow Management" from "Extended Accounting Management (Flow)" and so on. This is represented in the final.spec and updated acctadm.1m files in the case directory. I'm marking the case closed approved as of today. Gary.. From Darren.Reed@sun.com Thu Feb 21 13:22:16 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1LLMGtl028699 for ; Thu, 21 Feb 2008 13:22:16 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1LLMF8R029950 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 21 Feb 2008 13:22:16 -0800 (PST) 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 <0JWL00F07Y13S900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 21 Feb 2008 13:22:15 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWL00BJVY11OT20@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 21 Feb 2008 13:22:14 -0800 (PST) Received: from fe-apac-02.sun.com (fe-apac-02.sun.com [192.18.19.173] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1LLMH6o027595 for ; Thu, 21 Feb 2008 21:22:17 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JWL00D01VJ9PU00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 22 Feb 2008 05:22:13 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JWL00IKUY0ZOWJ0@mail-apac.sun.com>; Fri, 22 Feb 2008 05:22:13 +0800 (SGT) Date: Thu, 21 Feb 2008 13:22:11 -0800 From: Darren Reed Subject: Re: Extended Account Conversion to SMF [PSARC/2008/087 FastTrack timeout 02/14/2008] In-reply-to: <47B1E508.7040309@sun.com> Sender: Darren.Reed@sun.com To: Menno Lageman Cc: PSARC-ext@sun.com, Gary Winiger Message-id: <47BDEB83.3030005@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-au, en X-PMX-Version: 5.2.0.264296 References: <200802072222.m17MMmTw015385@sac.sfbay.sun.com> <47ABBA25.3080405@Sun.COM> <47AC0F79.8010302@sun.com> <47ACB010.1010001@Sun.COM> <47ACCB35.20409@sun.com> <47B13D08.3050507@Sun.COM> <47B1E508.7040309@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 288 Menno Lageman wrote: > ... > The smf state (general/enabled) is only interesting insofar as to see > whether or not the current configuration will be applied on the next > boot. Nothing more. Yes, I was somewhat dense in not accepting that limitation. Sorry for the trouble. Darren From sacadmin Wed May 7 17:08:03 2008 Received: from dm-eng-02.sfbay.sun.com (dm-eng-02.SFBay.Sun.COM [129.146.11.32]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m48082lB023959 for ; Wed, 7 May 2008 17:08:02 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m48081N1017081; Wed, 7 May 2008 17:08:01 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id m480893E012170; Wed, 7 May 2008 17:08:09 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id m48089PR012169; Wed, 7 May 2008 17:08:09 -0700 (PDT) Date: Wed, 7 May 2008 17:08:09 -0700 (PDT) From: Gary Winiger Message-Id: <200805080008.m48089PR012169@marduk.eng.sun.com> To: psarc-record@sac.sfbay.sun.com Cc: Menno.Lageman@sun.com, bjw@eng.sun.com, dil@sun.com, gww@eng.sun.com, lianep@eng.sun.com Subject: Contract between PSARC/2008/087 and PSARC/2002/547 Status: RO Content-Length: 119 I've executed a contract for extended accounting to use the upgrade file and linked the contact in both cases. Gary..