From lianep@nihil.sfbay.sun.com Tue Jan 12 18:38:19 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 o0D2cJ0G018668 for ; Tue, 12 Jan 2010 18:38:19 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0D2cIa2028845; Tue, 12 Jan 2010 20:38:18 -0600 (CST) 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 <0KW50050DZBUQE00@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Jan 2010 18:38:18 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW50038RZBTIN20@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Jan 2010 18:38:17 -0800 (PST) Received: from nihil.sfbay.sun.com (nihil.SFBay.Sun.COM [129.146.228.161]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0D2cHFI022938; Tue, 12 Jan 2010 18:38:17 -0800 (PST) Received: from nihil.sfbay.sun.com (localhost [127.0.0.1]) by nihil.sfbay.sun.com (8.14.4+Sun/8.14.4) with ESMTP id o0D2VsPs917730; Tue, 12 Jan 2010 18:31:54 -0800 (PST) Received: (from lianep@localhost) by nihil.sfbay.sun.com (8.14.4+Sun/8.14.4/Submit) id o0D2Vs0T917727; Tue, 12 Jan 2010 18:31:54 -0800 (PST) Date: Tue, 12 Jan 2010 18:31:54 -0800 (PST) From: Liane Praza Subject: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] To: PSARC-ext@sun.com Cc: Thomas.Whitten@sun.com, Truong.Q.Nguyen@sun.com, swilcox@sun.com Message-id: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 11063 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2010 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: SMF Early Manifest Import 1.2. Name of Document Author/Supplier: Author: Sean Wilcox 1.3 Date of This Document: 12 January, 2010 4. Technical Description 1. Summary smf(5)/Greenline (PSARC 2002/547) provides the manifest-import process, that imports manifest files from supported directories under /var/svc/manifest and /var/svc/manifest/site. The manifest-import process runs late in the boot process due to a dependency on the system/filesystem/minimal service. It is desirable to have this process run much earlier in the boot process, specifically before any services are started. 2. Details In the current environment, there is a problem when the manifest for an existing service is upgraded. Since the manifest-import service runs relatively late in the boot process, it is possible that the service with the upgraded manifest can start before the manifest-import service runs. If this happens, the SMF repository will contain old information -- not the configuration from the upgraded manifest. The Early Manifest Import project solves this problem by importing manifests before any services are started. This ensures that the repository will contain information from the latest manifests when the services are started. Thus, the services will not read stale configuration information from the repository. Early Manifest Import will be a service. The service will have a repository entry that describes it and gives it's state. Although, the service will be solely executed by the svc.startd process before any other services are initiated. The service can be disabled, and the svc.startd process will not execute Early Manifest Import during the early boot process. Manifest files will be imported from a new location that is available at the time Early Manifest Import is executed. Root (/) will be available, and as part of that /lib will be available. Therefore manifest files located under /lib/svc/manifest and /lib/svc/manifest/site will be imported during the execution of Early Manifest Import. As part of this project, the ON manifest files that are currently delivered under /var/svc/manifest will be moved to /lib/svc/manifest. After this change, the recommended best practice is manifest files be delivered under /lib/svc/manifest subtrees to take advantage of Early Manifest Import. Services delivered under the /var/svc/manifest directory tree will still be supported. Although, they will be imported during Late Manifest Import, specifically by the current manifest-import process. /lib/svc/method/manifest-import will be used to do the work of import and cleanup of manifests added and removed from the system during Early Manifest Import. Manifest files under the /lib/svc/manifest subtree will be imported during this phase. Those under the /var/svc/manifest will be imported during the Late Manifest Import which will run as the current manifest-import today with the dependency on filesystem/minimal ensuring that /var/svc/manifest subtree is available. The Late Manifest Import service will import manifests from /lib/svc as well. This allows administrators and IPS to invoke "svcadm restart manifest-import" to install new/upgraded manifest files. /lib/svc/method/manifest-import will use a new feature of the svccfg import sub-command option to import all the manifests in a set of directories. Each manifest file in the directory subtree will be found and imported. The code will preserve the use of the project private SVCCFG_CHECKHASH environment variable as it is used in today's code during manifest import. If the SVCCFG_CHECKHASH environment variable is set, then manifest files will be imported only if there are changes present that cause the hash values in the smf/manifest table to be different. Since profiles are considered to be machine specific configuration and since they are designed to be modified by the system administrator, the location for profiles will be /etc/svc/profile and /var/svc/profile. Much like manifest import, only the profiles in /etc/svc/profile will be applied during early manifest import. The profiles in both directories will be applied during late manifest import. Neither Early Manifest Import nor Late Manifest Import will look for profiles under /lib/svc. 3. Interface Table svccfg import Committed /lib/svc/manifest Committed /etc/svc/profile Committed system/early-manifest-import:default Committed This case requests patch binding. 4. Additional Materials smf_bootstrap svccfg man page updates --- smf_bootstrap(5) --- smf_bootstrap.orig Mon Nov 23 09:04:22 2009 +++ smf_bootstrap.emi Wed Dec 16 16:11:08 2009 @@ -14,19 +14,38 @@ files. Manifest Loading at Boot - The svc:/system/manifest-import:default service uses - svccfg(1M) to import certain manifest files from the - /var/svc/manifest directory tree into the service configura- - tion repository. The service imports files that it has not - imported previously and those files which have changed since - the last time they were imported by the service. When a man- - ifest is imported by the service, a hash of the file that - includes its contents is recorded in a property group of the - svc:/smf/manifest service. The manifest-import service uses - the hash to determine whether the file has changed. See - svccfg(1M) for information on the svccfg import behavior for - services that already exist in the repository. + Manifests are processed in two different phases during boot. + In each phase, manifests are processed using svccfg(1M) to + import manifest files from well-known locations into the + service configuration repository. Imported manifest files are + those that have not been imported previously or have changed + since the last time they were imported. When a manifest is + imported, a hash of the file that includes its contents is + recorded in a property group of the svc:/smf/manifest service. + The hash is used to determine whether the file has changed. + See svccfg(1M) for information on the svccfg import behavior + for services that already exist in the repository. For manifests + installed under supported directory trees, /lib/svc/manifest and + /var/svc/manifest, the manifest-import process will remove + services and instances from the repository if manifest(s) + delivering those services were deleted form the system. + Instances will be removed from the repository if support for + those instances are removed from the supporting manifest files. + The svc:/system/early-manifest-import:default service is + responsible for the first manifest processing. This service + processes only manifests from the /lib/svc/manifest directory + tree before svc.startd(1M) initializes any services thus enabling + services delivered in /lib/svc/manifest to always start with their + most updated definition. This service executes prior to any other + instance or service. + + The svc:/system/manifest-import:default service handles the + second manifest processing and imports manifest files from + both /lib/svc/manifest and /var/svc/manifest directory trees, + in that respective order. + + Manifest Handling During Packaging Operations Service manifests within packages should be identified with the class manifest. Class action scripts that install and @@ -108,21 +127,23 @@ across any release boundary. Profile Application - The first time the existence of each of the three service - profiles listed below is detected, svc.startd(1M) automati- - cally applies the profile. + The first time the existence of each of the service + profiles listed below is detected, the profile is automati- + cally applied. - /var/svc/profile/generic.xml - /var/svc/profile/platform.xml + /etc/svc/profile/generic.xml + /etc/svc/profile/platform.xml + /etc/svc/profile/site.xml /var/svc/profile/site.xml + The svc:/system/early-manifest-import:default service applies + the system profiles in /etc/svc/profile while the + svc:/system/manifest-import:default service handles the + site.xml profile in /var/svc/profile. - The svc:/smf/manifest service is used in a similar fashion. - - SunOS 5.11 Last change: 25 Sep 2008 2 @@ -134,11 +155,12 @@ - Additional service profiles that characterize the activation - of various groups of service instances might be present in - /var/svc/profile. None of the /var/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 various groups + of service instances might be present in /etc/svc/profile + and /var/svc/profile. None of the additional profiles in the + mentioned directories are automatically applied to the + repository. A profile can be manually applied or re-applied + using svccfg(1M). SEE ALSO pkgadd(1M), pkgrm(1M), svcadm(1M), svccfg(1M), @@ -148,3 +170,12 @@ NOTES The present version of smf(5) does not support multiple repositories. + + Services delivered in /var/svc/manifest may run into upgrade + related issues where a service may be started with old + repository configuration since its updated manifest is not + yet imported. Similarly, a newly added service may not be + available or a deleted service is still started during boot + because its manifest file has not been processed. Developers + are strongly encouraged to move manifest to /lib/svc/manifest + to avoid these issues. --- svccfg(1M) --- svccfg.orig Mon Nov 23 09:04:22 2009 +++ svccfg.emi Mon Nov 23 09:04:22 2009 @@ -235,8 +235,13 @@ fails. - import [-V] file + import [-V] [file | directory] + If a directory is supplied, for each manifest file found + in the directory tree, the service manifest file is imported + as stated below. Only files with a .xml extension are + considered for import when a directory is searched. + If file is a service manifest, then the services and instances it specifies are imported into the repository. According to the file, dependencies may be created in 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@sun.com Wed Jan 13 01:38:30 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 o0D9cUvA009069 for ; Wed, 13 Jan 2010 01:38:30 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0D9cTUi021925 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 13 Jan 2010 01:38:29 -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 <0KW600B11IS50400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 02:38:29 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW600EM7IS350B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 02:38:28 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0D9cRZ9019639 for ; Wed, 13 Jan 2010 09:38:27 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW600H00H45V300@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 09:38:27 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW600A88IRU2E10@fe-emea-10.sun.com>; Wed, 13 Jan 2010 09:38:18 +0000 (GMT) Date: Wed, 13 Jan 2010 09:38:17 +0000 From: Darren J Moffat Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Liane Praza Cc: PSARC-ext@sun.com, Thomas.Whitten@sun.com, Truong.Q.Nguyen@sun.com, swilcox@sun.com Message-id: <4B4D9489.10204@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091124) Status: RO Content-Length: 190 I don't see any issues with this. The case answered everything I expected, including changing the recommendation to deliver in /lib/. So I'll happily give this my +1. -- Darren J Moffat From Calum.Mackay@sun.com Wed Jan 13 09:14:29 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 o0DHETLA016831 for ; Wed, 13 Jan 2010 09:14:29 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0DHEOxI017994 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 13 Jan 2010 09:14:28 -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 <0KW70097H3W4KU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 10:14:28 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW7001SA3W2IZ50@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 10:14:27 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0DHEQ4C025179 for ; Wed, 13 Jan 2010 17:14:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW7000003O38Z00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 17:14:22 +0000 (GMT) Received: from [192.168.12.29] ([unknown] [212.44.17.104]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW700EXH3VNNF40@fe-emea-09.sun.com>; Wed, 13 Jan 2010 17:14:11 +0000 (GMT) Date: Wed, 13 Jan 2010 17:14:10 +0000 From: Calum Mackay Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> Sender: Calum.Mackay@sun.com To: Liane Praza Cc: PSARC-ext@sun.com, Thomas.Whitten@sun.com, Truong.Q.Nguyen@sun.com, swilcox@sun.com Message-id: <4B4DFF62.2090009@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 Status: RO Content-Length: 409 Liane, > Services delivered under the /var/svc/manifest directory tree will > still be supported. Although, they will be imported during Late > Manifest Import, specifically by the current manifest-import process. Would there be any advantage in having the Early process also import the /var manifests *if* /var/svc/manifest/ is available (which is presumably a common case)? cheers, calum. From liane.praza@Sun.COM Wed Jan 13 09:21:02 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 o0DHL2Sl017043 for ; Wed, 13 Jan 2010 09:21:02 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0DHKx2Z004037; Wed, 13 Jan 2010 09:21:00 -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 <0KW700A0P46Z7I00@brm-avmta-1.central.sun.com>; Wed, 13 Jan 2010 10:20:59 -0700 (MST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW7001VB46YIO80@brm-avmta-1.central.sun.com>; Wed, 13 Jan 2010 10:20:59 -0700 (MST) Received: from [10.7.251.216] (punchin-lianep.SFBay.Sun.COM [10.7.251.216]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0DHKujF336835; Wed, 13 Jan 2010 09:20:57 -0800 (PST) Date: Wed, 13 Jan 2010 09:20:55 -0800 From: Liane Praza Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <4B4DFF62.2090009@sun.com> To: Calum Mackay Cc: Liane Praza , PSARC-ext@Sun.COM, Thomas.Whitten@Sun.COM, Truong.Q.Nguyen@Sun.COM, swilcox@Sun.COM Message-id: <4B4E00F7.4080005@sun.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 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> <4B4DFF62.2090009@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 1045 Calum Mackay wrote: > Liane, > >> Services delivered under the /var/svc/manifest directory tree will >> still be supported. Although, they will be imported during Late >> Manifest Import, specifically by the current manifest-import process. > > Would there be any advantage in having the Early process also import the > /var manifests *if* /var/svc/manifest/ is available (which is presumably > a common case)? I'll let the project team speak up if I'm misrepresenting, but the very significant disadvantage of doing this is that it will obscure bugs in the less common case, and lead both us and ISVs to deliver services in /var/svc/manifest that work on upgrade correctly only if /var is not separate. (Because some service which was delivered in / depends on configuration delivered in /var which isn't there until /var/svc/manifest is imported on upgrade.) It's better to be predictable and behave the same in both cases, and find bugs for a less-common but still frequent configuration in all situations. liane From Calum.Mackay@Sun.COM Wed Jan 13 09:43:17 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 o0DHhHKh017732 for ; Wed, 13 Jan 2010 09:43:17 -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.4) with ESMTP id o0DHhFjE019934 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 13 Jan 2010 10:43:17 -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 <0KW700C1T584LZ00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 10:43:16 -0700 (MST) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW7001E9583IOA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 10:43:16 -0700 (MST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0DHhEjJ025129 for ; Wed, 13 Jan 2010 17:43:15 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW700B004SZJV00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 17:42:51 +0000 (GMT) Received: from [192.168.12.29] ([unknown] [212.44.17.104]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW700K3P56WI370@fe-emea-10.sun.com>; Wed, 13 Jan 2010 17:42:34 +0000 (GMT) Date: Wed, 13 Jan 2010 17:42:32 +0000 From: Calum Mackay Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <4B4E00F7.4080005@sun.com> Sender: Calum.Mackay@Sun.COM To: Liane Praza Cc: Liane Praza , PSARC-ext@Sun.COM, Thomas.Whitten@Sun.COM, Truong.Q.Nguyen@Sun.COM, swilcox@Sun.COM Message-id: <4B4E0608.20204@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> <4B4DFF62.2090009@sun.com> <4B4E00F7.4080005@sun.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 Status: RO Content-Length: 222 On 13/01/10 17:20, Liane Praza wrote: > It's better to be predictable and behave the same in both cases, and > find bugs for a less-common but still frequent configuration in all > situations. OK, thanks. cheers, calum. From Scott.Rotondo@Sun.COM Wed Jan 13 14:01:34 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 o0DM1YvH026047 for ; Wed, 13 Jan 2010 14:01:34 -0800 (PST) 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 o0DM1UEM037750 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 13 Jan 2010 15:01:34 -0700 (MST) 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 <0KW70061FH6LBC00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 14:01:33 -0800 (PST) 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 <0KW700MYUH6K4KE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 14:01:33 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o0DM1WSv028836 for ; Wed, 13 Jan 2010 22:01:32 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW700B00H280B00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 15:01:32 -0700 (MST) Received: from [129.146.108.62] ([unknown] [129.146.108.62]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW7008X1H6HXJ10@mail-amer.sun.com>; Wed, 13 Jan 2010 15:01:30 -0700 (MST) Date: Wed, 13 Jan 2010 14:01:29 -0800 From: Scott Rotondo Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> Sender: Scott.Rotondo@Sun.COM To: Liane Praza Cc: PSARC-ext@Sun.COM, Thomas.Whitten@Sun.COM, Truong.Q.Nguyen@Sun.COM, swilcox@Sun.COM Message-id: <4B4E42B9.2020602@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1117 > Manifest files will be imported from a new location that is available > at the time Early Manifest Import is executed. Root (/) will be > available, and as part of that /lib will be available. Therefore > manifest files located under /lib/svc/manifest and /lib/svc/manifest/site > will be imported during the execution of Early Manifest Import. > As part of this project, the ON manifest files that are currently > delivered under /var/svc/manifest will be moved to /lib/svc/manifest. > After this change, the recommended best practice is manifest files > be delivered under /lib/svc/manifest subtrees to take advantage of > Early Manifest Import. This (logical) recommendation leads to another question: Is there a particular situation where one should prefer/require late import of a manifest? If not, would it make sense to eliminate Late Manifest Import and leave /var/svc/manifest as a symlink to /lib/svc/manifest? Scott -- Scott Rotondo Principal Engineer, Solaris Security Technologies President, Trusted Computing Group Phone/FAX: +1 408 850 3655 (Internal x68278) From thomas.whitten@sun.com Wed Jan 13 14:18:54 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 o0DMIsoj026341 for ; Wed, 13 Jan 2010 14:18:54 -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.4) with ESMTP id o0DMIrfZ052172; Wed, 13 Jan 2010 15:18:53 -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 <0KW700J6BHZGGO00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Jan 2010 14:18:52 -0800 (PST) Received: from anthrax.Central.Sun.COM ([172.20.26.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW7007CQHZEXI60@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Jan 2010 14:18:50 -0800 (PST) Received: from anthrax.Central.Sun.COM (localhost [127.0.0.1]) by anthrax.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id o0DMIn5H018029; Wed, 13 Jan 2010 15:18:49 -0700 (MST) Received: (from tw21770@localhost) by anthrax.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id o0DMInar018028; Wed, 13 Jan 2010 15:18:49 -0700 (MST) Date: Wed, 13 Jan 2010 15:18:49 -0700 From: Tom Whitten Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <4B4E42B9.2020602@sun.com> To: Scott Rotondo Cc: Liane Praza , PSARC-ext@sun.com, Truong.Q.Nguyen@sun.com, swilcox@sun.com Reply-to: thomas.whitten@sun.com Message-id: <19278.18121.509367.596056@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.18 under Emacs 20.7.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> <4B4E42B9.2020602@sun.com> X-Authentication-warning: anthrax.Central.Sun.COM: tw21770 set sender to thomas.whitten@sun.com using -f Status: RO Content-Length: 1774 Scott Rotondo writes: > > Manifest files will be imported from a new location that is available > > at the time Early Manifest Import is executed. Root (/) will be > > available, and as part of that /lib will be available. Therefore > > manifest files located under /lib/svc/manifest and /lib/svc/manifest/site > > will be imported during the execution of Early Manifest Import. > > As part of this project, the ON manifest files that are currently > > delivered under /var/svc/manifest will be moved to /lib/svc/manifest. > > After this change, the recommended best practice is manifest files > > be delivered under /lib/svc/manifest subtrees to take advantage of > > Early Manifest Import. > > This (logical) recommendation leads to another question: Is there a > particular situation where one should prefer/require late import of a > manifest? We wanted to continue to support manifest in /var, so that non-ON consolidations and third party developers would not need to abruptly change their packages. > > If not, would it make sense to eliminate Late Manifest Import and leave > /var/svc/manifest as a symlink to /lib/svc/manifest? In the early phases of the EMI project, we actually considered making /var/svc/manifest a symlink. The feedback that we received, however, indicated that it would no play well with SVR4 packaging. See http://mail.opensolaris.org/pipermail/smf-discuss/2008-April/004111.html. We also received indications that the symlink would not play well with pkg(5), but I don't have any emails that I can refer you to for that. tom > > Scott > > -- > Scott Rotondo > Principal Engineer, Solaris Security Technologies > President, Trusted Computing Group > Phone/FAX: +1 408 850 3655 (Internal x68278) From Milan.Jurik@sun.com Wed Jan 13 23:13:07 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 o0E7D7MO004982 for ; Wed, 13 Jan 2010 23:13:07 -0800 (PST) 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 o0E7D7kk010861 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 13 Jan 2010 23:13:07 -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 <0KW800J0B6PVZ400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 23:13:07 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW800FV26PTU380@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 13 Jan 2010 23:13:05 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0E7D4Mx024546 for ; Thu, 14 Jan 2010 07:13:04 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KW800K006LX7K00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 14 Jan 2010 07:12:59 +0000 (GMT) Received: from [78.45.37.190] ([unknown] [78.45.37.190]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KW8009J06PKGC40@fe-emea-09.sun.com>; Thu, 14 Jan 2010 07:12:56 +0000 (GMT) Date: Thu, 14 Jan 2010 08:12:54 +0100 From: Milan Jurik Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <19278.18121.509367.596056@gargle.gargle.HOWL> Sender: Milan.Jurik@sun.com To: Thomas.Whitten@sun.com Cc: Scott Rotondo , Liane Praza , PSARC-ext@sun.com, Truong.Q.Nguyen@sun.com, swilcox@sun.com Message-id: <1263453174.1585.9.camel@localhost> Organization: Sun Microsystems Czech MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> <4B4E42B9.2020602@sun.com> <19278.18121.509367.596056@gargle.gargle.HOWL> Status: RO Content-Length: 2026 Hi Tom, Tom Whitten píše v st 13. 01. 2010 v 15:18 -0700: > Scott Rotondo writes: > > > Manifest files will be imported from a new location that is available > > > at the time Early Manifest Import is executed. Root (/) will be > > > available, and as part of that /lib will be available. Therefore > > > manifest files located under /lib/svc/manifest and /lib/svc/manifest/site > > > will be imported during the execution of Early Manifest Import. > > > As part of this project, the ON manifest files that are currently > > > delivered under /var/svc/manifest will be moved to /lib/svc/manifest. > > > After this change, the recommended best practice is manifest files > > > be delivered under /lib/svc/manifest subtrees to take advantage of > > > Early Manifest Import. > > > > This (logical) recommendation leads to another question: Is there a > > particular situation where one should prefer/require late import of a > > manifest? > > We wanted to continue to support manifest in /var, so that non-ON > consolidations and third party developers would not need to abruptly change > their packages. > > > > > If not, would it make sense to eliminate Late Manifest Import and leave > > /var/svc/manifest as a symlink to /lib/svc/manifest? > > In the early phases of the EMI project, we actually considered making > /var/svc/manifest a symlink. The feedback that we received, however, > indicated that it would no play well with SVR4 packaging. See > http://mail.opensolaris.org/pipermail/smf-discuss/2008-April/004111.html. > We also received indications that the symlink would not play well with > pkg(5), but I don't have any emails that I can refer you to for that. > But that is problem of packaging system (both of them), which should be fixed to deal with such situations (is it the first time when we are doing such change on filesystem hierarchy?). Why should we introduce such misleading "duplication" of places? Any benefit to have 2 places? Best regards, Milan From bart.smaalders@sun.com Thu Jan 14 13:46:03 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 o0ELk3PO006127 for ; Thu, 14 Jan 2010 13:46:03 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0ELk0B0025368; Thu, 14 Jan 2010 13:46:01 -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 <0KW900K07B4OHX00@brm-avmta-1.central.sun.com>; Thu, 14 Jan 2010 14:46:00 -0700 (MST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW900IIEB4NIK20@brm-avmta-1.central.sun.com>; Thu, 14 Jan 2010 14:46:00 -0700 (MST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0ELiFGZ013824; Thu, 14 Jan 2010 21:44:15 +0000 (GMT) Date: Thu, 14 Jan 2010 13:43:57 -0800 From: Bart Smaalders Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <1263453174.1585.9.camel@localhost> To: Milan Jurik Cc: Thomas.Whitten@sun.com, Truong.Q.Nguyen@sun.com, Liane Praza , swilcox@sun.com, Scott Rotondo , PSARC-ext@sun.com Message-id: <4B4F901D.5090401@Sun.COM> Organization: Sun Microsystems 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 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> <4B4E42B9.2020602@sun.com> <19278.18121.509367.596056@gargle.gargle.HOWL> <1263453174.1585.9.camel@localhost> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20091207 Thunderbird/3.0 Status: RO Content-Length: 1521 On 01/13/10 23:12, Milan Jurik wrote: >> In the early phases of the EMI project, we actually considered making >> /var/svc/manifest a symlink. The feedback that we received, however, >> indicated that it would no play well with SVR4 packaging. See >> http://mail.opensolaris.org/pipermail/smf-discuss/2008-April/004111.html. >> We also received indications that the symlink would not play well with >> pkg(5), but I don't have any emails that I can refer you to for that. >> > > But that is problem of packaging system (both of them), which should be > fixed to deal with such situations (is it the first time when we are > doing such change on filesystem hierarchy?). Why should we introduce > such misleading "duplication" of places? Any benefit to have 2 places? > > Best regards, > > Milan > > > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org The issue is that if some package treat /var/svc/manifest as a symlink, and others as a directory, we'll end up w/ problems. The packaging system cannot deal with discordant views of the file system hierarchy in a rational fashion. We can always fix the packages in the wos, but third parties may deliver SMF manifests to a directory named /var/svc/manifest for years. It's best that we leave it there to prevent problems. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird." From liane.praza@sun.com Thu Jan 14 13:59:09 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 o0ELx9JX006807 for ; Thu, 14 Jan 2010 13:59:09 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0ELx5hO027774; Thu, 14 Jan 2010 15:59:06 -0600 (CST) 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 <0KW900101BQH9L00@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Jan 2010 13:59:05 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KW900CSEBQH3NE0@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Jan 2010 13:59:05 -0800 (PST) Received: from [129.146.228.161] (nihil.SFBay.Sun.COM [129.146.228.161]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0ELx561811192; Thu, 14 Jan 2010 13:59:05 -0800 (PST) Date: Thu, 14 Jan 2010 13:59:05 -0800 From: Liane Praza Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <4B4F901D.5090401@Sun.COM> To: Bart Smaalders Cc: Milan Jurik , Thomas.Whitten@sun.com, Truong.Q.Nguyen@sun.com, swilcox@sun.com, Scott Rotondo , PSARC-ext@sun.com Message-id: <4B4F93A9.60301@sun.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 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> <4B4E42B9.2020602@sun.com> <19278.18121.509367.596056@gargle.gargle.HOWL> <1263453174.1585.9.camel@localhost> <4B4F901D.5090401@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.5) Gecko/20091207 Lightning/1.0pre Thunderbird/3.0 Status: RO Content-Length: 1908 On 01/14/10 01:43 PM, Bart Smaalders wrote: > On 01/13/10 23:12, Milan Jurik wrote: > >>> In the early phases of the EMI project, we actually considered making >>> /var/svc/manifest a symlink. The feedback that we received, however, >>> indicated that it would no play well with SVR4 packaging. See >>> http://mail.opensolaris.org/pipermail/smf-discuss/2008-April/004111.html. >>> >>> We also received indications that the symlink would not play well with >>> pkg(5), but I don't have any emails that I can refer you to for that. >>> >> >> But that is problem of packaging system (both of them), which should be >> fixed to deal with such situations (is it the first time when we are >> doing such change on filesystem hierarchy?). Why should we introduce >> such misleading "duplication" of places? Any benefit to have 2 places? > The issue is that if some package treat /var/svc/manifest as a symlink, > and others as a directory, we'll end up w/ problems. The packaging > system cannot deal with discordant views of the file system hierarchy > in a rational fashion. We can always fix the packages in the wos, but > third parties may deliver SMF manifests to a directory named > /var/svc/manifest for years. It's best that we leave it there to prevent > problems. Right. It makes no sense to place the burden on the project team to fix all Sun-delivered, third-party, and home-grown packaging or install software systems to ensure that they cope with an ARC-Committed directory changing to a symlink. The fact that we have two examples which are not tolerant to it today was taken by the project team as a sign that they should pursue another course of action, and they did. The high-level point here is that we're talking about a filesystem location which is Committed as a delivery directory for ISVs and customers, so it must be handled with care in order to maintain compatibility. liane From Joep.Vesseur@sun.com Fri Jan 15 00:29:38 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 o0F8Tchh004084 for ; Fri, 15 Jan 2010 00:29:38 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0F8TbJL022571 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 00:29:37 -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 <0KWA00J0B4XDNU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 01:29:37 -0700 (MST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA007XC4XCKJ60@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 01:29:36 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0F8TYVk016839 for ; Fri, 15 Jan 2010 08:29:36 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA005003MTXY00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 08:29:32 +0000 (GMT) Received: from enigma.Holland.Sun.COM ([unknown] [10.16.117.32]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA00GWT4X7Q3F0@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 08:29:31 +0000 (GMT) Date: Fri, 15 Jan 2010 09:29:26 +0100 From: Joep Vesseur Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <4B4F93A9.60301@sun.com> Sender: Joep.Vesseur@sun.com Cc: PSARC-ext@sun.com Message-id: <4B502766.5010402@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> <4B4E42B9.2020602@sun.com> <19278.18121.509367.596056@gargle.gargle.HOWL> <1263453174.1585.9.camel@localhost> <4B4F901D.5090401@Sun.COM> <4B4F93A9.60301@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.1.5) Gecko/20091201 Lightning/1.0b1 Thunderbird/3.0 Status: RO Content-Length: 445 On 01/14/10 22:59, Liane Praza wrote: >> The issue is that if some package treat /var/svc/manifest as a symlink, >> and others as a directory, we'll end up w/ problems. Not that I'm in favor of unlimited amounts of LOFS-mounts but, in theory, /var/svc/manifest could have /lib/svc/manifest mounted on top of it. There are issues with that too, just like with two separate manifest directories. I just wanted to highlight the alternative. Joep From Milan.Jurik@Sun.COM Fri Jan 15 01:32:55 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 o0F9Wt1G005204 for ; Fri, 15 Jan 2010 01:32:55 -0800 (PST) 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 o0F9Ws3t009057 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 01:32:54 -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 <0KWA0001P7UUDO00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 01:32:54 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00HRO7USBW60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 01:32:53 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0F9WqB8025563 for ; Fri, 15 Jan 2010 09:32:52 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00M0064VX800@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 09:32:33 +0000 (GMT) Received: from [129.157.18.63] ([unknown] [129.157.18.63]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA000JD7TS5UG0@fe-emea-10.sun.com>; Fri, 15 Jan 2010 09:32:16 +0000 (GMT) Date: Fri, 15 Jan 2010 10:32:14 +0100 From: Milan Jurik Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <4B4F901D.5090401@Sun.COM> Sender: Milan.Jurik@Sun.COM To: Bart Smaalders Cc: Thomas.Whitten@Sun.COM, Truong.Q.Nguyen@Sun.COM, swilcox@Sun.COM, Scott Rotondo , PSARC-ext@Sun.COM Message-id: <1263547934.8434.15.camel@xylabone> Organization: Sun Microsystems - Prague Czech Republic MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> <4B4E42B9.2020602@sun.com> <19278.18121.509367.596056@gargle.gargle.HOWL> <1263453174.1585.9.camel@localhost> <4B4F901D.5090401@Sun.COM> Status: RO Content-Length: 2042 Hi Bart, Bart Smaalders píše v čt 14. 01. 2010 v 13:43 -0800: > On 01/13/10 23:12, Milan Jurik wrote: > > >> In the early phases of the EMI project, we actually considered making > >> /var/svc/manifest a symlink. The feedback that we received, however, > >> indicated that it would no play well with SVR4 packaging. See > >> http://mail.opensolaris.org/pipermail/smf-discuss/2008-April/004111.html. > >> We also received indications that the symlink would not play well with > >> pkg(5), but I don't have any emails that I can refer you to for that. > >> > > > > But that is problem of packaging system (both of them), which should be > > fixed to deal with such situations (is it the first time when we are > > doing such change on filesystem hierarchy?). Why should we introduce > > such misleading "duplication" of places? Any benefit to have 2 places? > > > > Best regards, > > > > Milan > > > > > > > > _______________________________________________ > > opensolaris-arc mailing list > > opensolaris-arc@opensolaris.org > > > The issue is that if some package treat /var/svc/manifest as a symlink, > and others as a directory, we'll end up w/ problems. The packaging > system cannot deal with discordant views of the file system hierarchy > in a rational fashion. We can always fix the packages in the wos, but > third parties may deliver SMF manifests to a directory named > /var/svc/manifest for years. It's best that we leave it there to prevent > problems. > I am very well aware of this problem but these situations happen from time to time. It would be good to find some solution. Because IPS has no interactive support (yet?), then such special case (symlink vs. dir) could be evaluated based on "package importance". Not sure if it can be 100% safe, some analysis would be needed. But that is packaging system problem, not for this case and not for I-team of this case, of course. Why not obsolete /var/svc/manifest? Has I-team some usage of it in the future except backward compatibility? Best regards, Milan From liane.praza@sun.com Fri Jan 15 06:45:38 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 o0FEjcjB009180 for ; Fri, 15 Jan 2010 06:45:38 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0FEjZ3R021741; Fri, 15 Jan 2010 06:45:35 -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 <0KWA0083BMBYQK00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jan 2010 06:45:34 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA003QLMBWDD80@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Jan 2010 06:45:32 -0800 (PST) Received: from [10.7.251.216] (punchin-lianep.SFBay.Sun.COM [10.7.251.216]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0FEjVH5963173; Fri, 15 Jan 2010 06:45:31 -0800 (PST) Date: Fri, 15 Jan 2010 06:45:31 -0800 From: Liane Praza Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <1263547934.8434.15.camel@xylabone> To: Milan Jurik Cc: Bart Smaalders , Thomas.Whitten@sun.com, Truong.Q.Nguyen@sun.com, swilcox@sun.com, Scott Rotondo , PSARC-ext@sun.com Message-id: <4B507F8B.4040307@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> <4B4E42B9.2020602@sun.com> <19278.18121.509367.596056@gargle.gargle.HOWL> <1263453174.1585.9.camel@localhost> <4B4F901D.5090401@Sun.COM> <1263547934.8434.15.camel@xylabone> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 956 Milan Jurik wrote: > Why not obsolete /var/svc/manifest? Has I-team some usage of it in the > future except backward compatibility? From a very long-term interface stability goal point of view, Obsolete, but not EOFed would be OK. SMF would need to support it for quite some time though, so it would just be a paperwork step. The only explicit issue I see with marking it obsolete is that there is no customer alternative available, especially in older releases of S10. Customers and ISVs who need their software to work across all releases which have SMF would need to continue knowingly use /var/svc/manifest. (Most non-OS services are not particularly vulnerable to the bugs that can crop up from being part of late manifest import.) Through the Obsolete, I wouldn't want to give our customers/ISVs the impression that we were not going to support their multi-release deliveries of SMF services. So I'm thinking it's premature. liane From Milan.Jurik@sun.com Fri Jan 15 06:56:25 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 o0FEuPfm009524 for ; Fri, 15 Jan 2010 06:56:25 -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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0FEuN0i028948 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 15 Jan 2010 06:56:24 -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 <0KWA00J2NMU0EQ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 06:56:24 -0800 (PST) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWA00E9KMTZ0HF0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 06:56:23 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o0FEuMYm008774 for ; Fri, 15 Jan 2010 14:56:22 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KWA00F00LR4UE00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 15 Jan 2010 14:56:10 +0000 (GMT) Received: from [129.157.18.63] ([unknown] [129.157.18.63]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KWA00DCFMTGQA20@fe-emea-10.sun.com>; Fri, 15 Jan 2010 14:56:05 +0000 (GMT) Date: Fri, 15 Jan 2010 15:56:02 +0100 From: Milan Jurik Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <4B507F8B.4040307@sun.com> Sender: Milan.Jurik@sun.com To: Liane Praza Cc: Bart Smaalders , Thomas.Whitten@sun.com, Truong.Q.Nguyen@sun.com, swilcox@sun.com, Scott Rotondo , PSARC-ext@sun.com Message-id: <1263567362.8434.47.camel@xylabone> Organization: Sun Microsystems - Prague Czech Republic MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> <4B4E42B9.2020602@sun.com> <19278.18121.509367.596056@gargle.gargle.HOWL> <1263453174.1585.9.camel@localhost> <4B4F901D.5090401@Sun.COM> <1263547934.8434.15.camel@xylabone> <4B507F8B.4040307@sun.com> Status: RO Content-Length: 1107 Hi Liane, Liane Praza píše v pá 15. 01. 2010 v 06:45 -0800: > Milan Jurik wrote: > > Why not obsolete /var/svc/manifest? Has I-team some usage of it in the > > future except backward compatibility? > > From a very long-term interface stability goal point of view, Obsolete, > but not EOFed would be OK. SMF would need to support it for quite some > time though, so it would just be a paperwork step. > > The only explicit issue I see with marking it obsolete is that there is > no customer alternative available, especially in older releases of S10. > Customers and ISVs who need their software to work across all releases > which have SMF would need to continue knowingly use /var/svc/manifest. > (Most non-OS services are not particularly vulnerable to the bugs that > can crop up from being part of late manifest import.) > > Through the Obsolete, I wouldn't want to give our customers/ISVs the > impression that we were not going to support their multi-release > deliveries of SMF services. So I'm thinking it's premature. > OK, thank you for the answer. Best regards, Milan From liane.praza@sun.com Wed Jan 20 10:10:37 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 o0KIAbE3012412 for ; Wed, 20 Jan 2010 10:10:37 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o0KIATih016143; Wed, 20 Jan 2010 12:10:36 -0600 (CST) 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 <0KWK00C0755O1700@nwk-avmta-2.sfbay.sun.com>; Wed, 20 Jan 2010 10:10:36 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KWK00A8G55NQI40@nwk-avmta-2.sfbay.sun.com>; Wed, 20 Jan 2010 10:10:36 -0800 (PST) Received: from [10.7.251.216] (punchin-lianep.SFBay.Sun.COM [10.7.251.216]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id o0KIAZsf150122; Wed, 20 Jan 2010 10:10:35 -0800 (PST) Date: Wed, 20 Jan 2010 10:10:34 -0800 From: Liane Praza Subject: Re: SMF Early Manifest Import [PSARC/2010/013 FastTrack timeout 01/20/2010] In-reply-to: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> To: Liane Praza Cc: PSARC-ext@sun.com, Thomas.Whitten@sun.com, Truong.Q.Nguyen@sun.com, swilcox@sun.com Message-id: <4B57471A.5020703@sun.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 References: <201001130231.o0D2Vs0T917727@nihil.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20091027) Status: RO Content-Length: 91 This case was approved at PSARC today. There are no changes to the original spec. liane