From sacadmin Tue May 4 11:50:11 2010 Received: from nihil.Eng.Sun.COM (nihil.SFBay.Sun.COM [129.146.228.161]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o44IoBgv014516; Tue, 4 May 2010 11:50:11 -0700 (PDT) Received: from nihil.Eng.Sun.COM (localhost [127.0.0.1]) by nihil.Eng.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o44IoB58102023; Tue, 4 May 2010 11:50:11 -0700 (PDT) Received: (from lianep@localhost) by nihil.Eng.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o44IoBg2102020; Tue, 4 May 2010 11:50:11 -0700 (PDT) Date: Tue, 4 May 2010 11:50:11 -0700 (PDT) From: Liane Praza Message-Id: <201005041850.o44IoBg2102020@nihil.Eng.Sun.COM> To: PSARC-record@sac.sfbay.sun.com Subject: SMF Site Profile Directory [PSARC/2010/152 Self Review] Status: RO Content-Length: 596 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: SMF Site Profile Directory 1.2. Name of Document Author/Supplier: Author: Tony Nguyen 1.3 Date of This Document: 04 May, 2010 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: Automatic 6.6. ARC Exposure: open From liane.praza@oracle.com Tue May 4 11:54:17 2010 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 o44IsHCm014806 for ; Tue, 4 May 2010 11:54:17 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o44IsHZT002271 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 4 May 2010 11:54:17 -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 <0L1W00K0ZSIH3U00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 04 May 2010 12:54:17 -0600 (MDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1W003KOSIGT8B0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 04 May 2010 12:54:16 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o44IsG03016940 for ; Tue, 04 May 2010 18:54:16 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o44IhFxR005803 for ; Tue, 04 May 2010 18:54:15 +0000 (GMT) Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 236102581272999225; Tue, 04 May 2010 11:53:45 -0700 Received: from [129.146.228.161] (/129.146.228.161) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 May 2010 11:53:44 -0700 Date: Tue, 04 May 2010 11:53:40 -0700 From: Liane Praza Subject: PSARC 2010/152 SMF Site Profile Directory To: psarc-ext@sun.com Cc: Tony Nguyen Message-id: <4BE06D34.9010602@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4BE06D57.00CB:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 5160 I'm submitting this proposal on behalf of Tony Nguyen. It's submitted as closed-approved-automatic because it was reviewed on smf-discuss, and is a fairly straightforward extension to an existing mechanism. I appreciate it may be a little on the line, so am happy to convert it to a fasttrack if there are substantial questions or people would like more time to comment. liane --- 1. Introduction 1.1. Project/Component Working Name: A directory for site profiles 1.2. Name of Document Author/Supplier: Tony.Q.Nguyen@oracle.com 4. Technical Description: Summary: SMF allows administrator(s) and administrative tools to deliver service customizations into /etc/svc/profile/site.xml profile which is applied once during system/early-manifest-import. Essentially, all customizations via profile must be delivered at the same time which prevents administrators from incrementally customize the system by delivering multiple profiles and forces administrative tools to coordinate their use of a single site.xml file. These shortcomings really limit the benefit for profiles. For example, Distribution Constructor provides a smf_service_profile section to allow specification of profiles to be manually applied during image build process and auto-installer also manually applies network_nwam.xml during boot. All these manual profile applications can be removed if there's support for automatic applying a set of administrative profiles during boot. This project delivers a new empty /etc/svc/profile/site directory in which administrators and administrative tools can deliver service customization profiles. Profiles in /etc/svc/profile/site are applied once at boot during system/early-manifest-import. On a running system, administrator can put new profiles into /etc/svc/profile/site and restart system/manifest-import to apply the new profiles. Current profile behaviors are preserved, namely: - profiles are applied only once, i.e. updated profiles are not re-applied - profile unapplying is not supported - no ordering support for profiles /etc/svc/profile/site.xml profile is still supported for backward compatibility. /usr/sbin/svccfg apply subcommand is also enhanced to accept a directory containing profiles. Interfaces: New profile directory processed during manifest import: /etc/svc/profile/site Committed svccfg apply takes either file or directory argument: svccfg apply file|directory Committed No incompatible change is proposed, so this case seeks patch binding, though no backport is explicitly planned. Doc Impact: svccfg(1M) --- svccfg.orig Wed Apr 21 23:32:07 2010 +++ svccfg.new Thu Apr 22 00:10:53 2010 @@ -1,7 +1,7 @@ Service Profile Subcommands - apply [-n] file + apply [-n] file|directory - If a file is a service profile, properties, including + If argument is a service profile, properties, including general/enabled, that are specified in the file are modified in the SMF repository. Not-yet-existent proper- ties and property groups will be created. The type of @@ -17,5 +17,10 @@ description of service profiles. This command requires privileges to modify properties in the service and instance. See smf_security(5) for the privileges - required to modify properties. If file is not a service - profile, the subcommand fails. + required to modify properties. + + If argument is a directory, all profiles found under that + directory tree will get applied as described above. The + subcommand fails if specified file or any file found under + specified directory is not a service profile. + smf_bootstrap(5) --- smf_bootstrap.orig Thu Apr 22 00:34:37 2010 +++ smf_bootstrap.new Thu Apr 22 00:33:44 2010 @@ -7,11 +7,16 @@ /etc/svc/profile/platform.xml /etc/svc/profile/site.xml - The svc:/smf/manifest service is used in a similar fashion. + Except for the three mentioned profiles, none of the + /etc/svc/profile profiles are automatically applied to the + repository. A profile can be manually applied or re-applied + using svccfg(1M). - Additional service profiles that characterize the activation - of various groups of service instances might be present in - /etc/svc/profile. None of the /etc/svc/profile profiles are - automatically applied to the repository. A profile can be - manually applied or re-applied using svccfg(1M). + The /etc/svc/profile/site directory is delivered to contain + additional site specific profiles which also get applied by + system manifest import services. Administrators and + administrative tools can place new profiles into this + directory and restart system/manifest-import or reboot the + system to apply the new profiles. + The svc:/smf/manifest service is used in a similar fashion. From john.fischer@oracle.com Tue May 4 12:15:53 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o44JFqcN015302 for ; Tue, 4 May 2010 12:15:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o44JFpmV011843 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 4 May 2010 14:15:52 -0500 (CDT) 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 <0L1W00M09TIGIN00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 04 May 2010 13:15:52 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1W003H4TIFT6D0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 04 May 2010 13:15:51 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o44JFp29028974 for ; Tue, 04 May 2010 19:15:51 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o44FRuCK003940 for ; Tue, 04 May 2010 19:15:45 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt354.oracle.com with ESMTP id 236179291273000460; Tue, 04 May 2010 12:14:20 -0700 Received: from [10.7.250.1] (/10.7.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 May 2010 12:14:19 -0700 Date: Tue, 04 May 2010 12:14:13 -0700 From: John Fischer Subject: Re: PSARC 2010/152 SMF Site Profile Directory In-reply-to: <4BE06D34.9010602@oracle.com> To: Liane Praza Cc: psarc-ext@sun.com, Tony Nguyen Message-id: <4BE07205.2080400@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE07265.01C7:SCFMA4539814,ss=1,fgs=0 References: <4BE06D34.9010602@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100302 Lightning/1.0b1 Thunderbird/3.0.2 Status: RO Content-Length: 5642 Tony, This looks fine. My only question is what is the release binding? Would it be a Minor release of Solaris or a Patch release of Solaris? I think a Minor release of Solaris. Also the site.xml file should be declared Obsolete Committed. Right? Thanks, John On 05/ 4/10 11:53 AM, Liane Praza wrote: > I'm submitting this proposal on behalf of Tony Nguyen. It's submitted > as closed-approved-automatic because it was reviewed on smf-discuss, > and is a fairly straightforward extension to an existing mechanism. I > appreciate it may be a little on the line, so am happy to convert it > to a fasttrack if there are substantial questions or people would like > more time to comment. > > liane > > --- > 1. Introduction > 1.1. Project/Component Working Name: > A directory for site profiles > 1.2. Name of Document Author/Supplier: > Tony.Q.Nguyen@oracle.com > > 4. Technical Description: > > Summary: > > SMF allows administrator(s) and administrative tools to deliver > service customizations into /etc/svc/profile/site.xml profile which > is applied once during system/early-manifest-import. Essentially, all > customizations via profile must be delivered at the same time which > prevents administrators from incrementally customize the system by > delivering multiple profiles and forces administrative tools to > coordinate their use of a single site.xml file. These shortcomings > really limit the benefit for profiles. For example, Distribution > Constructor provides a smf_service_profile section to allow > specification of profiles to be manually applied during image build > process and auto-installer also manually applies network_nwam.xml > during boot. All these manual profile applications can be removed > if there's support for automatic applying a set of administrative > profiles during boot. > > This project delivers a new empty /etc/svc/profile/site directory in > which administrators and administrative tools can deliver service > customization profiles. Profiles in /etc/svc/profile/site are applied > once at boot during system/early-manifest-import. On a running system, > administrator can put new profiles into /etc/svc/profile/site and > restart system/manifest-import to apply the new profiles. Current > profile behaviors are preserved, namely: > > - profiles are applied only once, i.e. updated profiles are not > re-applied > - profile unapplying is not supported > - no ordering support for profiles > > /etc/svc/profile/site.xml profile is still supported for backward > compatibility. /usr/sbin/svccfg apply subcommand is also enhanced to > accept a directory containing profiles. > > Interfaces: > > New profile directory processed during manifest import: > > /etc/svc/profile/site Committed > > svccfg apply takes either file or directory argument: > > svccfg apply file|directory Committed > > No incompatible change is proposed, so this case seeks patch binding, > though no backport is explicitly planned. > > Doc Impact: > svccfg(1M) > > --- svccfg.orig Wed Apr 21 23:32:07 2010 > +++ svccfg.new Thu Apr 22 00:10:53 2010 > @@ -1,7 +1,7 @@ > Service Profile Subcommands > - apply [-n] file > + apply [-n] file|directory > > - If a file is a service profile, properties, including > + If argument is a service profile, properties, including > general/enabled, that are specified in the file are > modified in the SMF repository. Not-yet-existent proper- > ties and property groups will be created. The type of > @@ -17,5 +17,10 @@ > description of service profiles. This command requires > privileges to modify properties in the service and > instance. See smf_security(5) for the privileges > - required to modify properties. If file is not a service > - profile, the subcommand fails. > + required to modify properties. > + > + If argument is a directory, all profiles found under that > + directory tree will get applied as described above. The > + subcommand fails if specified file or any file found under > + specified directory is not a service profile. > + > > smf_bootstrap(5) > > --- smf_bootstrap.orig Thu Apr 22 00:34:37 2010 > +++ smf_bootstrap.new Thu Apr 22 00:33:44 2010 > @@ -7,11 +7,16 @@ > /etc/svc/profile/platform.xml > /etc/svc/profile/site.xml > > - The svc:/smf/manifest service is used in a similar fashion. > + Except for the three mentioned profiles, none of the > + /etc/svc/profile profiles are automatically applied to the > + repository. A profile can be manually applied or re-applied > + using svccfg(1M). > > - Additional service profiles that characterize the activation > - of various groups of service instances might be present in > - /etc/svc/profile. None of the /etc/svc/profile profiles are > - automatically applied to the repository. A profile can be > - manually applied or re-applied using svccfg(1M). > + The /etc/svc/profile/site directory is delivered to contain > + additional site specific profiles which also get applied by > + system manifest import services. Administrators and > + administrative tools can place new profiles into this > + directory and restart system/manifest-import or reboot the > + system to apply the new profiles. > > + The svc:/smf/manifest service is used in a similar fashion. From liane.praza@oracle.com Tue May 4 13:15:06 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o44KF6s1016604 for ; Tue, 4 May 2010 13:15:06 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o44KF5Iu017483 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Tue, 4 May 2010 15:15:05 -0500 (CDT) 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 <0L1W0052JW95DW00@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 04 May 2010 14:15:05 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1W00334W94ZU10@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Tue, 04 May 2010 14:15:04 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o44KF3SQ026474 for ; Tue, 04 May 2010 20:15:03 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o44AcxRi017384 for ; Tue, 04 May 2010 20:15:00 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 214102161273004051; Tue, 04 May 2010 13:14:11 -0700 Received: from [129.146.228.161] (/129.146.228.161) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 May 2010 13:14:09 -0700 Date: Tue, 04 May 2010 13:14:08 -0700 From: Liane Praza Subject: Re: PSARC 2010/152 SMF Site Profile Directory In-reply-to: <4BE07205.2080400@oracle.com> To: John Fischer Cc: psarc-ext@sun.com, Tony Nguyen Message-id: <4BE08010.90306@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BE08046.00E8:SCFMA4539814,ss=1,fgs=0 References: <4BE06D34.9010602@oracle.com> <4BE07205.2080400@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 536 On 05/ 4/10 12:14 PM, John Fischer wrote: > Tony, > > This looks fine. > > My only question is what is the release binding? Would it > be a Minor release of Solaris or a Patch release of Solaris? > I think a Minor release of Solaris. It's patch, as there are no explicit compatibility issues. Though, as the case says, there's no plan to backport. > > Also the site.xml file should be declared Obsolete Committed. > Right? I didn't see a need to mark it Obsolete at this point. If there's a specific concern, let us know. liane From garrett.damore@oracle.com Wed May 5 07:01:44 2010 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 o45E1iH3026017 for ; Wed, 5 May 2010 07:01: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.4) with ESMTP id o45E1g58034640 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 5 May 2010 08:01:43 -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 <0L1Y00F1Z9MVGQ00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 May 2010 07:01:43 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00JS79MUGJ40@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 May 2010 07:01:42 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45E1gOo026725 for ; Wed, 05 May 2010 14:01:42 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o457vNXB025018 for ; Wed, 05 May 2010 14:01:39 +0000 (GMT) Received: from abhmt008.oracle.com by acsmt354.oracle.com with ESMTP id 216256111273068005; Wed, 05 May 2010 07:00:05 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 07:00:01 -0700 Date: Wed, 05 May 2010 06:59:57 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2010/152 SMF Site Profile Directory In-reply-to: <4BE07205.2080400@oracle.com> To: John Fischer Cc: Liane Praza , psarc-ext@sun.com, Tony Nguyen Message-id: <4BE179DD.8050302@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BE17A45.0148:SCFMA4539814,ss=1,fgs=0 References: <4BE06D34.9010602@oracle.com> <4BE07205.2080400@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100131 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 6090 I tend to agree that from an architectural perspective, the site.xml might better be handled as Obsolete -- it seems that the new mechanism is superior. I also agree that Patch (as specified in the document) is fine for this case. - Garrett On 05/ 4/10 12:14 PM, John Fischer wrote: > Tony, > > This looks fine. > > My only question is what is the release binding? Would it > be a Minor release of Solaris or a Patch release of Solaris? > I think a Minor release of Solaris. > > Also the site.xml file should be declared Obsolete Committed. > Right? > > Thanks, > > John > > > On 05/ 4/10 11:53 AM, Liane Praza wrote: >> I'm submitting this proposal on behalf of Tony Nguyen. It's >> submitted as closed-approved-automatic because it was reviewed on >> smf-discuss, and is a fairly straightforward extension to an existing >> mechanism. I appreciate it may be a little on the line, so am happy >> to convert it to a fasttrack if there are substantial questions or >> people would like more time to comment. >> >> liane >> >> --- >> 1. Introduction >> 1.1. Project/Component Working Name: >> A directory for site profiles >> 1.2. Name of Document Author/Supplier: >> Tony.Q.Nguyen@oracle.com >> >> 4. Technical Description: >> >> Summary: >> >> SMF allows administrator(s) and administrative tools to deliver >> service customizations into /etc/svc/profile/site.xml profile which >> is applied once during system/early-manifest-import. Essentially, all >> customizations via profile must be delivered at the same time which >> prevents administrators from incrementally customize the system by >> delivering multiple profiles and forces administrative tools to >> coordinate their use of a single site.xml file. These shortcomings >> really limit the benefit for profiles. For example, Distribution >> Constructor provides a smf_service_profile section to allow >> specification of profiles to be manually applied during image build >> process and auto-installer also manually applies network_nwam.xml >> during boot. All these manual profile applications can be removed >> if there's support for automatic applying a set of administrative >> profiles during boot. >> >> This project delivers a new empty /etc/svc/profile/site directory in >> which administrators and administrative tools can deliver service >> customization profiles. Profiles in /etc/svc/profile/site are applied >> once at boot during system/early-manifest-import. On a running >> system, >> administrator can put new profiles into /etc/svc/profile/site and >> restart system/manifest-import to apply the new profiles. Current >> profile behaviors are preserved, namely: >> >> - profiles are applied only once, i.e. updated profiles are not >> re-applied >> - profile unapplying is not supported >> - no ordering support for profiles >> >> /etc/svc/profile/site.xml profile is still supported for backward >> compatibility. /usr/sbin/svccfg apply subcommand is also enhanced to >> accept a directory containing profiles. >> >> Interfaces: >> >> New profile directory processed during manifest import: >> >> /etc/svc/profile/site Committed >> >> svccfg apply takes either file or directory argument: >> >> svccfg apply file|directory Committed >> >> No incompatible change is proposed, so this case seeks patch binding, >> though no backport is explicitly planned. >> >> Doc Impact: >> svccfg(1M) >> >> --- svccfg.orig Wed Apr 21 23:32:07 2010 >> +++ svccfg.new Thu Apr 22 00:10:53 2010 >> @@ -1,7 +1,7 @@ >> Service Profile Subcommands >> - apply [-n] file >> + apply [-n] file|directory >> >> - If a file is a service profile, properties, including >> + If argument is a service profile, properties, including >> general/enabled, that are specified in the file are >> modified in the SMF repository. Not-yet-existent proper- >> ties and property groups will be created. The type of >> @@ -17,5 +17,10 @@ >> description of service profiles. This command requires >> privileges to modify properties in the service and >> instance. See smf_security(5) for the privileges >> - required to modify properties. If file is not a service >> - profile, the subcommand fails. >> + required to modify properties. >> + >> + If argument is a directory, all profiles found under that >> + directory tree will get applied as described above. The >> + subcommand fails if specified file or any file found under >> + specified directory is not a service profile. >> + >> >> smf_bootstrap(5) >> >> --- smf_bootstrap.orig Thu Apr 22 00:34:37 2010 >> +++ smf_bootstrap.new Thu Apr 22 00:33:44 2010 >> @@ -7,11 +7,16 @@ >> /etc/svc/profile/platform.xml >> /etc/svc/profile/site.xml >> >> - The svc:/smf/manifest service is used in a similar fashion. >> + Except for the three mentioned profiles, none of the >> + /etc/svc/profile profiles are automatically applied to the >> + repository. A profile can be manually applied or re-applied >> + using svccfg(1M). >> >> - Additional service profiles that characterize the activation >> - of various groups of service instances might be present in >> - /etc/svc/profile. None of the /etc/svc/profile profiles are >> - automatically applied to the repository. A profile can be >> - manually applied or re-applied using svccfg(1M). >> + The /etc/svc/profile/site directory is delivered to contain >> + additional site specific profiles which also get applied by >> + system manifest import services. Administrators and >> + administrative tools can place new profiles into this >> + directory and restart system/manifest-import or reboot the >> + system to apply the new profiles. >> >> + The svc:/smf/manifest service is used in a similar fashion. > From liane.praza@oracle.com Wed May 5 08:48:38 2010 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 o45FmctR028004 for ; Wed, 5 May 2010 08:48:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45FmbRc021199 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 5 May 2010 08:48:38 -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 <0L1Y00L0ZEL1IC00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 May 2010 08:48:37 -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 <0L1Y00KVIEL0ZD00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 May 2010 08:48:37 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45FmaxY004069 for ; Wed, 05 May 2010 15:48:36 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45ANND2028127 for ; Wed, 05 May 2010 15:48:35 +0000 (GMT) Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 239394591273074513; Wed, 05 May 2010 08:48:33 -0700 Received: from [10.7.251.216] (/10.7.251.216) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 08:48:32 -0700 Date: Wed, 05 May 2010 08:48:26 -0700 From: Liane Praza Subject: Re: PSARC 2010/152 SMF Site Profile Directory In-reply-to: <4BE179DD.8050302@oracle.com> To: "Garrett D'Amore" Cc: John Fischer , psarc-ext@sun.com, Tony Nguyen Message-id: <4BE1934A.5030103@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4BE19354.0031:SCFMA4539814,ss=1,fgs=0 References: <4BE06D34.9010602@oracle.com> <4BE07205.2080400@oracle.com> <4BE179DD.8050302@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 1242 On 05/05/10 06:59, Garrett D'Amore wrote: > I tend to agree that from an architectural perspective, the site.xml > might better be handled as Obsolete -- it seems that the new mechanism > is superior. The new mechanism is identical, so the site.xml location simply augments the site directory with the same semantics, and costs us very little to maintain. I don't see a real benefit in marking it obsolete committed at this point, but if the ARC really wants that modification, it certainly causes no change in the implementation, and we can trivially make that change in the materials. Generally, I don't choose the Obsolete Committed direction for interfaces unless if we truly can't get rid of something but there's a new interface with truly superior and new features. (For things we get benefit from removing and can actually remove, I go straight to EOF as quickly as possible.) In this case, the semantics are the same, so there's no real benefit to encouraging customers to convert if they're happy specifying a monolithic profile rather than one in fragments. IOW, Obsolete Committed for site.xml wouldn't be my choice, but it's also not critical enough to quibble, and I suspect Tony will feel the same. :) liane From garrett.damore@oracle.com Wed May 5 08:55:09 2010 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 o45Ft9r1028446 for ; Wed, 5 May 2010 08:55:09 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45Ft9Ro024031 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 5 May 2010 08:55:09 -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 <0L1Y00L0JEVXS600@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 May 2010 08:55:09 -0700 (PDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00KDVEVWZC10@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 May 2010 08:55:08 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o45Ft7dN000384 for ; Wed, 05 May 2010 15:55:08 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o457NRpa006866 for ; Wed, 05 May 2010 15:55:06 +0000 (GMT) Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 239411911273074818; Wed, 05 May 2010 08:53:38 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 08:53:37 -0700 Date: Wed, 05 May 2010 08:53:36 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2010/152 SMF Site Profile Directory In-reply-to: <4BE1934A.5030103@oracle.com> To: Liane Praza Cc: John Fischer , psarc-ext@sun.com, Tony Nguyen Message-id: <4BE19480.6020005@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4BE194DB.008A:SCFMA4539814,ss=1,fgs=0 References: <4BE06D34.9010602@oracle.com> <4BE07205.2080400@oracle.com> <4BE179DD.8050302@oracle.com> <4BE1934A.5030103@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 2340 On 05/ 5/10 08:48 AM, Liane Praza wrote: > On 05/05/10 06:59, Garrett D'Amore wrote: >> I tend to agree that from an architectural perspective, the site.xml >> might better be handled as Obsolete -- it seems that the new mechanism >> is superior. > > The new mechanism is identical, so the site.xml location simply > augments the site directory with the same semantics, and costs us very > little to maintain. > > I don't see a real benefit in marking it obsolete committed at this > point, but if the ARC really wants that modification, it certainly > causes no change in the implementation, and we can trivially make that > change in the materials. > > Generally, I don't choose the Obsolete Committed direction for > interfaces unless if we truly can't get rid of something but there's a > new interface with truly superior and new features. (For things we > get benefit from removing and can actually remove, I go straight to > EOF as quickly as possible.) In this case, the semantics are the > same, so there's no real benefit to encouraging customers to convert > if they're happy specifying a monolithic profile rather than one in > fragments. My take on these things is: 1) If there is a clear preference of one interface vs. another that customers should use (and the interfaces offer identical functionality with no reason to use the less preferred), then we ought to make it Obsolete. 2) Eventually, cleaning up duplicate code is a good thing. 3) Duplicate interfaces (like locations to store config data) can cause future problems for other software, that has to be aware of all possible locations (and may run into the same problems that created the rationale for this case in the first place.) All these make me believe we should mark the site.xml interface "Obsolete" to discourage its use, and remove it when it is easy to do so. > > IOW, Obsolete Committed for site.xml wouldn't be my choice, but it's > also not critical enough to quibble, and I suspect Tony will feel the > same. :) Obsolete Committed seems unfortunate -- is there a reason this needs to be Committed? It seems like this could be decommitted somewhat for the Solaris Next release? Is this file used on Solaris 10? (I don't recall the history behind site.xml.) If not, then we could just nuke it now. - Garrett From liane.praza@oracle.com Wed May 5 09:22:35 2010 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 o45GMZjT029019 for ; Wed, 5 May 2010 09:22:35 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o45GMZtA006123 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 5 May 2010 09:22:35 -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 <0L1Y00M03G5NSX00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 May 2010 09:22:35 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L1Y00KCOG5NZ630@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 May 2010 09:22:35 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o45GMYDx017266 for ; Wed, 05 May 2010 16:22:34 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45C5G1o002249 for ; Wed, 05 May 2010 16:22:34 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 216730711273076546; Wed, 05 May 2010 09:22:26 -0700 Received: from [10.7.251.216] (/10.7.251.216) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 09:22:21 -0700 Date: Wed, 05 May 2010 09:22:19 -0700 From: Liane Praza Subject: Re: PSARC 2010/152 SMF Site Profile Directory In-reply-to: <4BE19480.6020005@oracle.com> To: "Garrett D'Amore" Cc: John Fischer , psarc-ext@sun.com, Tony Nguyen Message-id: <4BE19B3B.6080500@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0201.4BE19B4A.0174:SCFMA4539814,ss=1,fgs=0 References: <4BE06D34.9010602@oracle.com> <4BE07205.2080400@oracle.com> <4BE179DD.8050302@oracle.com> <4BE1934A.5030103@oracle.com> <4BE19480.6020005@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100315 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 805 On 05/05/10 08:53, Garrett D'Amore wrote: > Obsolete Committed seems unfortunate -- is there a reason this needs to > be Committed? It seems like this could be decommitted somewhat for the > Solaris Next release? Is this file used on Solaris 10? (I don't recall > the history behind site.xml.) If not, then we could just nuke it now. Yes. smf_bootstrap(5). It's an administrative-only interface. Only administrators were expected to populate it -- no Solaris software could deliver to that file. It would be unfriendly to deployers with little benefit to us if we removed support for it. The site directory as defined in this case already applies a set of profile fragments -- site.xml is now just another one of those fragments. (Even though it's not explicitly under the directory.) liane From garrett.damore@oracle.com Wed May 5 09:32:45 2010 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 o45GWiBM029235 for ; Wed, 5 May 2010 09:32:44 -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.4) with ESMTP id o45GWgUR005554 for <@sunmail2sca.sfbay.sun.com:psarc-ext@sun.com>; Wed, 5 May 2010 10:32:44 -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 <0L1Y00001GMKGQ00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 May 2010 09:32:44 -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 <0L1Y00K50GMJZ640@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Wed, 05 May 2010 09:32:43 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o45GWg0L002691 for ; Wed, 05 May 2010 16:32:43 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o458vfW6029423 for ; Wed, 05 May 2010 16:32:42 +0000 (GMT) Received: from abhmt014.oracle.com by acsmt354.oracle.com with ESMTP id 216767781273077161; Wed, 05 May 2010 09:32:41 -0700 Received: from [10.7.251.172] (/10.7.251.172) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 09:32:41 -0700 Date: Wed, 05 May 2010 09:32:39 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2010/152 SMF Site Profile Directory In-reply-to: <4BE19B3B.6080500@oracle.com> To: Liane Praza Cc: John Fischer , psarc-ext@sun.com, Tony Nguyen Message-id: <4BE19DA7.6030506@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BE19DAA.00E5:SCFMA4539814,ss=1,fgs=0 References: <4BE06D34.9010602@oracle.com> <4BE07205.2080400@oracle.com> <4BE179DD.8050302@oracle.com> <4BE1934A.5030103@oracle.com> <4BE19480.6020005@oracle.com> <4BE19B3B.6080500@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 939 On 05/ 5/10 09:22 AM, Liane Praza wrote: > On 05/05/10 08:53, Garrett D'Amore wrote: >> Obsolete Committed seems unfortunate -- is there a reason this needs to >> be Committed? It seems like this could be decommitted somewhat for the >> Solaris Next release? Is this file used on Solaris 10? (I don't recall >> the history behind site.xml.) If not, then we could just nuke it now. > > Yes. smf_bootstrap(5). It's an administrative-only interface. Only > administrators were expected to populate it -- no Solaris software > could deliver to that file. > > It would be unfriendly to deployers with little benefit to us if we > removed support for it. The site directory as defined in this case > already applies a set of profile fragments -- site.xml is now just > another one of those fragments. (Even though it's not explicitly > under the directory.) > > liane Ok. I'll defer to your judgment on the matter. - Garrett